なぜ「DNS のモード」がゲームと銀行アプリを同時に左右するのか

Clash Meta（Mihomo コア）を使いこなしている人ほど、最後に悩むのがDNS の enhanced-modeです。代表的な二択が fake-ip と redir-host で、どちらも「名前解決を Clash 側で握る」という点は同じでも、アプリが最初に受け取る IP の意味が根本的に違います。前者は応答を速くしやすい一方、後者は実サーバの IP に近い情報をルール評価に載せやすい、というトレードオフです。

その結果、同じノードでもFPS やオンライン対戦の体感が重いように感じたり、ネット銀行や公共系のサイトだけ証明書エラーやログインループになったりします。ここを「ルールを足せば直る」とだけ考えると、実際には DNS の段階で経路が食い違っているケースを取りこぼします。本稿では、この二択を用途別に選び、切り替え、ログで検証するまでを一続きでまとめます。分流の大枠は国内直通と海外プロキシの分流記事、非ブラウザ全体を拾う話はTUN モード詳解と併読すると理解が早いです。

fake-ip と redir-host の違い（実務で効くポイントだけ）

fake-ip は、クライアントが名前解決を求めたときに、まず 198.18.0.0/16 などプライベート帯の仮アドレスを返します。その後 Clash がドメインとトラフィックの対応を内部で保持し、実接続フェーズで本解決やルール評価を進めます。ローカルでの「最初の一手」が速くなりやすく、ブラウザや多くのアプリでは体感のキレが良くなる傾向があります。

一方 redir-host は、名前解決の結果として実際の A/AAAA レコードに近い値をアプリ側に返す流れになりやすく、ルールが IP-CIDR や GEOIP に依存する場合の解釈が素直です。国内サイトが「接続元の IP と DNS の答えの整合」を厳しめに見るとき、あるいは同じドメインでも地域で答えが変わる CDNを使うとき、トラブルが出にくいことがあります。

💡
覚えておく一行 「速さと相性」のトレードオフです。体感の速さ・ルールの単純さを取るなら fake-ip、国内系サービスとの相性・IP ベースのルールの素直さを取るなら redir-host、が最初の分岐になります。

設定ファイルでの指定イメージ（概念スニペット）

実際のキー名は利用中のコア版・GUI のマージ欄に合わせてください。ここでは Mihomo 系でよく触る dns.enhanced-mode を例にします。

# Example — adjust keys to your profile and GUI merge layer
dns:
  enable: true
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 8.8.8.8
  fallback:
    - tls://dns.google
  fake-ip-filter:
    - "*.lan"
    - "*.local"

redir-host に切り替えるときは、おおむね enhanced-mode: redir-host に差し替え、fake-ip-range や fake-ip-filter の扱いをプロファイルに合わせて整理します。購読 YAML を直接いじれない場合は、クライアントの「設定の上書き」「プリペンド」機能で dns ブロックだけを足す方法もあります。詳しくはオーバーライド解説を参照してください。

ゲーム低遅延を優先するときの考え方

オンラインゲームで問題になりやすいのは、(1) DNS クエリ自体の遅延 (2) UDP を含むセッションが意図しない出口に出る (3) ルールが DOMAIN ベースなのに IP ベースの評価とズレるの三つです。ここで fake-ip は、(1) を抑えやすい反面、(3) の読み違いを生むことがあります。

実務的には、まずTUN モードやモジュールのキャプチャ範囲がゲームの実行ファイルを含んでいるかを確認します。次に、接続ログで対象ドメインがどのポリシーに流れたかを見ます。ログの読み方は接続ログの記事に任せるとして、DNS だけ切り替えて改善するかを A/B テストするのが早いです。

手順の例：(A) いま fake-ip で遅い・不安定なら、(B) 一時的に redir-host に戻し、(C) 同じマップ・同じ時間帯で再測定、(D) それでもダメならノードやルール順の問題に進む、の順が安全です。ゲームタイトルごとに最適解は変わるため、「世間のおすすめ設定を丸写し」より、ログで自分の環境のボトルネックを特定する方が再現性が高いです。

オンライン銀行・行政・国内大手を開きたいとき

ここではredir-host 寄りに寄せる判断が多いです。理由は、サービス側が DNS の応答と実接続元の整合、あるいは国内限定のエッジに誘導する仕組みを前提にしている場合があるからです。fake-ip のままだと、アプリやブラウザが一時的に仮アドレスを握った状態で挙動が変わり、証明書検証やリダイレクトだけ失敗、といった部分的症状が出ることがあります。

対策の方向性は二段構えが現実的です。第一段階として enhanced-mode を redir-host にし、nameserver を利用環境に合った国内系と信頼できるフォールバックの組み合わせに整えます。第二段階として、特定ドメインだけ fake-ip-filter 相当の除外や、domain ベースの DNS 分割（Clash の nameserver-policy など）で銀行ドメインだけは常に真面目に解かせる設計にします。

公共サービスや企業 VPN と併用する場合は、Clash 以外の DNS キャッシュや OS の「暗号化 DNS」も競合しがちです。切り替え後はブラウザだけでなくネイティブアプリも再テストし、失敗時はログにその FQDN が現れるかを確認してください。

切り替えと検証の実務ステップ

おすすめの流れは次のとおりです。(1) いまの dns ブロックをバックアップする。(2) GUI なら DNS 画面で enhanced-mode を切り替え、CLI なら設定を書き換えてコアをリロードする。(3) DNS キャッシュを捨てる（OS・ブラウザ・対象アプリの再起動）。(4) 問題のサービスだけを開き、接続ログでドメインとポリシー名を確認する。(5) 改善しないなら nameserver の順序や fallback-filter、ルールの並びを疑う。

このとき「fake-ip のまま銀行だけ直したい」場合は、まずそのドメインを fake-ip-filter に近い考え方で除外できるかを検討します。逆に「redir-host にしたら海外サイトだけ遅くなった」場合は、海外向けの解決を proxy-server-nameserver 系（環境に応じたキー）へ逃がす、といった分割が効きます。分流全体の設計は前述の分流記事とセットで見てください。

よくある詰まりどころと切り分け

  • ルールをいじっても変わらない：DNS がまだ OS 直叩きのまま。システムプロキシ／TUN の適用範囲と、ブラウザの「セキュア DNS」設定を確認します。
  • IPv6 だけ失敗する：AAAA の経路と、ノード側の IPv6 対応を疑います。必要なら一時的に IPv6 を切って挙動を比較します。
  • GEOIP が想定と違う：fake-ip 利用時はログやルールに出る IP が仮アドレスである可能性があります。redir-host に切り替えたうえで IP 系ルールを読み直すと整理しやすいです。

これらはすべて、「DNS モード」と「実際にマッチしたルール行」をセットで見ると筋が通ります。単一の設定値に理想形はなく、利用中の購読ルール・クライアント・OS の組み合わせごとに微調整するのが常です。

オープンソース情報と入手先

コアやクライアントのソースコード、Issue、ライセンスは各プロジェクトの GitHub で確認できます。初めてクライアントを導入する場合は、検証済みのパッケージ導線として当サイトのダウンロードページも併用してください。

まとめ

fake-ip は応答のキレと運用のしやすさ、redir-host は実 IP に基づくルールと国内系サービスとの相性、という住み分けが現場では扱いやすいです。ゲームの遅延感が DNS に起因するかどうか、銀行や公共サイトが名前解決の段階でつまずいていないかを、モード切り替えとログで一度ずつ確認すると、設定の迷子が大きく減ります。

環境に合った Clash Meta クライアントを用意し、DNS を含めたプロファイルをバックアップしながら試すのが安全です。準備が整ったら → Clash を無料ダウンロードし、DNS モードを自分の用途に合わせて最適化するところから始められます。