なぜ「DNS モードひとつ」で体感が変わるのか

Mihomo（Clash Meta）系では、トラフィックがルールどおりの出口に載るまでに名前解決と接続確立が絡みます。enhanced-mode をfake-ip にすると、対象ドメインにはクライアント側が用意した仮想 IPv4のような応答が返り、実際の向き先はコアが後段で決めます。redir-host は、ざっくり言うとより実アドレス寄りの解決結果を前提にしつつ、環境によってはアプリが見る IP と実経路の関係が fake-ip より素直に見える場面があります。

検索でよく出てくる「どっちが正解」という問いは、実務ではアプリの種類（ブラウザ／ゲーム／開発ツール）とTUN の有無、そして購読テンプレが前提にしているモードの三点セットで答えが変わります。だからこそ本稿ではClash Verge Rev の GUI と YAML の両方から、「いま自分がどちらを選んでいるか」を確実に突き止める手順を前面に出します。

fake-ip と redir-host：意思決定のための短い比較表

厳密なコア内部の分岐まで踏み込むより、運用で迷わないための見取り図として押さえてください。

  • fake-ip が向きやすい典型：ルール細分化やドメインベースの振り分けを多用し、TUNで広くトラフィックを掬いたい。初回接続の体感をDNS のラウンドトリップにあまり引きずられたくない。
  • redir-host が向きやすい典型：アプリが DNS 結果を検証したり、取得した IP と実通信の整合を気にする。特定サービスだけ奇妙な誤判定が fake-ip 時に出る。
  • 共通の落とし穴：nameserver の到達性が悪い、IPv6 が迂回して意図しない経路になる、セキュリティ製品がローカル DNS を書き換える——などはモードを替えても残るので先に切り分けます。
💡

バージョンや購読によりデフォルトの dns ブロックが異なります。画面で見えている値と実際にロードされた YAMLが一致しているかは、必ずエディタで確認すると安心です。

触る前のチェック：プロファイル・転送経路・IPv6

まずアクティブなプロファイルが操作対象かを確認します。複数購読を試していると、「設定画面で変えたつもりが別ファイルだった」が起きやすいです。続いてシステムプロキシとTUNのどちらでアプリを掬っているかを見ます。TUN を ON にするとDNS クエリの吸い上げ方が変わり、OS の設定だけでは説明できない症状が表に出ることがあります。

IPv6 が有効な環境では、A 記録と AAAA 記録のどちらが選ばれるかで挙動が変わります。fake-ip／redir-host を切り替えても改善しないときは、IPv6 を一時的に切って再現するか、ログで実際に選ばれたレコードを追うと原因が絞れます。汎用トラブルシュートのログの読み方も参照してください。

Clash Verge Rev の画面から DNS にアクセスする（Windows）

ビルドごとにラベルは多少変わりますが、だいたい次のどちらかでたどり着けます。（A）設定まわりに DNS の項目がある。（B）プロファイル編集で dns ブロックを直接開く。迷ったらサイドバーから設定／Profiles／編集といった語で探し、dns: という見出しが見えるまで進みます。

  • ダッシュボードでコアが停止していないか、無効化された機能がないかを確認する
  • 使用中のプロファイル名が期待どおりかを確認してから編集画面へ入る
  • enhanced-mode の行を探し、fake-ip またはredir-host を読み取る
  • nameserver、fallback、fake-ip-filter が購読の説明と整合しているかざっと見る

GUI が読み取り専用に見える構成でも、多くの場合外部エディタで開くかテキストとして書き戻す操作が用意されています。どちらの導線でも最終的に同じ YAML の dns ブロックが更新されていれば問題ありません。

YAML で確認する dns ブロックの要点

設定ファイルのdns: 以下には、少なくとも次がセットで現れることが多いです。enable が true であること。enhanced-mode が fake-ip か redir-host になっていること。nameserver に到達可能な上流 DNSが並んでいること。fallback やfallback-filter がGFW や社内フィルタの前提と矛盾していないこと。

fake-ip-range は、その名前のとおり仮想応答に使う帯域です。ほかのサブネットと衝突しない範囲を選ぶのが基本ですが、通常は購読提供者の既定値のままで運用する読者が大半です。fake-ip-filter は仮想応答から除外したい名前を並べます。社内ドメイン・LDAP・特定 CDN の検証などで効いてくるため、「モードは fake-ip のまま、例外だけ実アドレスに寄せる」という運用が現実的です。

手順：redir-host から fake-ip に寄せるとき

ルールの効きを優先し、ブラウジングの初動を軽くしたいときに試されやすいのが fake-ip への寄せです。操作としてはdns.enhanced-mode を fake-ip に変更し、購読テンプレがlistenやprefer-h3などDNS クライアント側のオプションを要求している場合は、その説明に沿って追加します。

変更後は設定の保存とコアの再読み込みを忘れずに。Windows ではアプリを再起動まで必要なビルドもあります。適用直後にブラウザを完全終了してから再度開くと、古い接続のキャッシュに惑わされにくいです。CLI ツールやコンテナが別経路で DNS を叩いている場合は、そちらは依然として OS のリゾルバを見ていることがあります。

⚠️

fake-ip は万能ではありません。アプリによっては見えている IP が実装詳細の影響を強く受けるため、症状が出たらフィルタで除外するかredir-host へ戻すのが早いです。

手順：fake-ip から redir-host に戻すとき

特定アプリだけ接続拒否や証明書まわりの警告が増えた、オンラインゲームのマッチングが不安定になった、といったときは redir-host 側へ一度戻して再現性を見るのが定石です。操作はenhanced-mode を redir-host に変更して保存・再読み込みまで同様です。

切り替え後に体感が重くなったように感じる場合は、上流 DNS の応答やルールのマッチ順が変わり、待ちが表面化しただけであることがあります。ログでどの nameserver が選ばれたか、該当ドメインがどのポリシーに刺さったかを確認すると、設定ミスと体感の差を切り分けられます。

効いたかを確認する：ログ・ブラウザ・dig の三段構え

確認は短時間で完了させるのがコツです。まずコアのログでDNS クエリとルールの結果が期待どおりかを見ます。次にブラウザで対象サイトをハードリロードし、タスクマネージャーやリソース監視で別プロセスが直結していないかを疑います。慣れている読者はnslookupやdigでどのリゾルバに聞いているかを切り替えながら比較すると差がはっきりします。

Chrome／Edge の Secure DNSや別ブラウザの DNS over HTTPSが有効だと、OS や Mihomo の経路をすっ飛ばすことがあります。調査中だけでもオフにして単一路に寄せると、fake-ip／redir-host の切替評価がぶれません。詳細なブラウザ側の整理はChrome と Secure DNS の稿も参照してください。

TUN・システムプロキシと Windows の DNS 設定の関係

TUN を有効にすると仮想アダプタ経由の経路が増え、名前解決の入口もアプリごとに変わり得ます。一方システムプロキシのみでは、プロキシ非対応のアプリがDNS を自分で処理してしまうことがあります。だから「Verge Rev で DNS を変えたのに効かない」は、経路が別であることが多いです。

対処の優先度としては、まず対象アプリがどの経路を使うかを決め打ちし、TUN が必要なら ON、そうでなければプロキシ対応アプリに限定するのが破綻しにくいです。モード記事（#60／#61）で触れたポリシーグループとは別軸ですが、出口を変える操作と名前解決の入口を変える操作がセットで効いて初めて期待どおりに見える、という整理になります。

よくある質問

fake-ip でだけ壊れるアプリがある

fake-ip-filter に該当ドメインや証明書検証に絡むホスト名を足して実アドレス側へ寄せるのが現実的です。それでも直らなければredir-hostへ切り替えて比較し、なお問題ならそのアプリはプロキシの外に置く設計も検討します。

redir-host なのに GEOIP がズレる

上流 DNS の所在地やECS の有無で返ってくるアドレスのバッチが変わります。またルール次第ではドメインより IP の方が先に効くケースもあります。ログで実際に選ばれたポリシー名まで落として確認してください。

IPv6 を切ると直るがよくない

それはIPv6 側の経路や DNS のフェイルオーバがボトルネックだったサインです。IPv6 を恒久無効にせず、upstream とルールで止血できるようにdnsとrulesをセットで見直すのが筋です。

まとめ：DNS はモード選びと経路設計のあいだをつなぐ

ワンボタン型の商業 VPN は手軽ですが、細かい経路制御や開発／運用の検証では「ブラウザと CLI とコンテナで名前解決の入口がバラバラ」になりやすく、結果として体感だけ不安定に見えることがあります。一方で Clash／Mihomo スタックは、ルールと DNS と転送経路を同じ設定の世界で説明できるのが強みで、fake-ip とredir-hostはその説明を実運用に落とすためのスイッチです。Windows で Clash Verge Rev をすでに触っている読者なら、本稿の順でGUI と YAML を突き合わせ、モードを一度ずつ切り替えてログまで確認すれば、「DNS が効いていない」のではなくどの経路が効いていないかまで踏み込めるはずです。長く保守されるコアと整理された GUI をそろえておけば、のちほどTUN やポリシーグループを足しても破綻しにくく、商用クライアントにありがちな経路の黒箱化や更新停滞とも対照的に、ログと設定で詰められる余地が残ります。環境を公式のクリーンな入手線から揃えたい方は→ Clash を無料ダウンロードして、快適な接続体験を始めるからどうぞ。