Clash Verge Rev(Windows):DNS の fake-ip と redir-host を切り替えて検証する実践ガイド
この記事で押さえること(検索の意図)
Clash Verge Rev を Windows に入れて購読まで取り込めたあと、検索で残りやすい論点のひとつがDNS まわりです。特に Mihomo(旧 Clash Meta)系では dns: ブロックの enhanced-mode に fake-ip と redir-host があり、「どちらを選べばよいか」「切り替えたあと名前解決と分流(ルール命中)が正常か自分でどう確かめるか」というユーザーの検索意図に本稿はピントを合わせます。総合チュートリアルやTUN の全体像とは役割を分け、単一機能としての DNS モード選択とセルフチェックに絞って書きます。
GUI のメニュー名は版によって変わりますが、背後のYAML とカーネルの意味論は安定しているので、画面上は「DNS」「名前解決」「enhanced」など近いラベルを探しつつ、本文では dns.enable・dns.listen・enhanced-mode という設定語で統一します。また Windows ではアダプタ DNS・IPv6・別製品のフィルタドライバが絡むと「YAML は正しいのに挙動だけおかしい」ことがあるため、そのときの切り分けの順序も末尾で短くまとめます。
まず結論:DNS は「名前」と「ルール」の接着剤
ルールベースのプロキシでは、接続しようとしているホスト名をどう解決するかが、その後の RULE 評価やプロキシグループへの振り分けに直結します。enhanced-mode をオンにした dns は、単なるキャッシュ付きフォワーダではなく、アプリケーションが見ている名前と接続確立時の情報をカーネル側で揃えやすくするための仕組みとして理解すると混乱が減ります。ここで fake-ip と redir-host のトレードオフが現れます。
- fake-ip:ドメインに対して偽の IP(fake-ip アドレス)を返し、その対応をカーネルが保持します。DOMAIN 系ルールや Sniffer と組み合わせたときに評価が素早く進むことがありますが、アプリやブラウザが「返ってきた IP」の見え方に依存するケースでは予期しない互換問題が出ることがあります。Sniffer とストリーミング周りの整理とセットで読むとイメージが掴みやすいです。
- redir-host:クライアントには実 IP(upstream の応答)を返しつつ、DNS クエリ自体は Clash 側のチェーンで処理するスタイルです。「実アドレスが見えていることが前提のアプリ」との相性トラブルを減らしたいときの選択肢になりやすい一方、ルールや環境によっては評価タイミングやログの読み方が変わるので、切り替え後は必ず検証が必要です。
覚えておくコツ:どちらが「正解」というより、自分の購読YAMLが前提にしているモードといま困っている症状の組み合わせで決めるものです。説明文だけ読んで決めるより、手元で一度ずつ切り替えて同じテスト手順でログを比較するのがいちばん早いです。
YAML のどこを見るか(Verge と設定ファイルの対応)
Clash Verge Rev では、プロファイル編集画面またはエクスポートしたテキストから dns: セクションを開きます。よく触るキーは次のような並びです(購読により追記・省略があります)。
enable: true… DNS 機能そのものを有効化しているか。listen:… どのアドレス/ポートで DNS に応答するか。Windows の他ソフトとポートが被らないかもここで確認します。enhanced-mode: fake-ipまたはredir-host… 本稿の主題。nameserver/fallback/nameserver-policy… 上流への問い合わせ順と例外。
GEOIP や DOMAIN-SUFFIX で国内を DIRECT に落とす構成では、DNS がどの出口から上流へ聞きに行っているかも結果に効きます。GEOIP と DNS の優先まわりの記事とあわせると、「ルールは合っているのに表示だけおかしい」系の誤認が減ります。
GUI と raw YAML:一部の版では DNS の一部だけ GUI に露出し、細部は購読由来のテンプレートに依存します。画面上で保存したつもりが購読更新で上書きされるパターンもあるので、恒久変更はプロファイルの編集方針(ローカルオーバーライドや別ファイルのマージ)まで含めて決めると安全です。
Windows の Verge でモードを変える(一般的な操作線)
以下は版差を吸収した一般的な手順です。実際のメニュー名が異なる場合は「設定」「DNS」「カーネル」「プロファイル」など近い階層をたどしてください。
- 現プロファイルのバックアップ:変更前に YAML を書き出すか、購読側でバージョン管理できる場所にコピーを残します。
- DNS ページまたはプロファイル編集を開く:
enhanced-modeに相当するドロップダウンやトグルを探します。 fake-ip↔redir-hostを切り替えて保存:ほかの dns キーをいじらず、まずは enhanced-mode だけを変えて差分を単純化します。- カーネルの再起動または設定リロード:反映ボタンやトレイメニューから Mihomo を再起動し、ログに致命的エラーがないか確認します。
- 検証フェーズへ:次節のチェックリストどおり、名前解決・ブラウザ・ログの三本で見ます。
注意:fake-ip-range や fake-ip-filter、IPv6 の扱いまで同時にいじると、トラブル時に原因が分岐しすぎます。初回の切替実験では enhanced-mode だけに絞るのがおすすめです。
切替後の検証①:Windows で名前解決の経路を見る
PowerShell またはコマンドプロンプトを開き、Clash が応答しているはずの DNS に明示的に問い合わせます。listen が :53 ではなく別ポートの場合は、環境に合わせてツールを選んでください(ポート付きの確認が必要な場合は 対応する問い合わせ方法を別途用意します)。
- 基本:テストドメインを一つ決め(例:よく使う海外サイトと国内サイトの両方)、同じ手順で二種類以上試します。
- fake-ip 時の読み方:返答がプライベート帯や運用で決めた fake-ip レンジに見えることがあります。これ単体を「異常」と決めつけず、ブラウザでの開き方とログのルール命中とセットで見ます。
- redir-host 時の読み方:上流から返った実 IP が見えるはずなので、思っているリージョンのレンジかざっくり比較します(厳密な地理位置判定ではありません)。
併せて、Windows の設定アプリ → ネットワークとインターネット で表示される DNS と、Clash の TUN/システムプロキシ設定が矛盾していないかを眺めるだけでも、「OS が別の DNS を見ている」典型的なミスに気づきやすくなります。
切替後の検証②:分流とログで「出口」を確認する
名前解決が期待どおりでも、ルール優先順位やプロセス/ドメインの別名で別グループに落ちているケースがあります。検証のコツは次のとおりです。
- テスト用に単純なルールを足してみる:自分で制御できるドメインなら、意図的に特定プロキシグループへ寄せる行を一時的に追加し、命中ログがその行を指すかを見ます(本番プロファイルで試すときは必ずバックアップを)。
- ブラウザだけでなく別アプリも:ブラウザはプロキシ設定や拡張の影響を受けやすいので、別アプリで同じホストを開いて比較すると切り分けが進みます。
- UDP/QUIC:特定サイトだけ遅い・繋がらないときは、ブラウザ側で HTTP/3 を切るなど暫定実験も有効です。根本はルールとノード側の許可ですが、DNS 調整とセットで症状が変わることがあります。
ノード側が全体的に不安定で、DNS 以前にタイムアウトが並んで見える場合は、レイテンシが総じて赤いときの総まとめに沿って UDP・STUN・DNS を広げると早いです。
症状別の素早い切り分け
モード変更直後だけ特定サイトが開けない
A. DNS キャッシュとブラウザキャッシュを一度空にし、別ブラウザでも再現するか確認します。証明書ピンニングや銀行アプリでは fake-ip 側が不利に働く事例があるので、その場合は redir-host へ寄せるか、該当ドメインを fake-ip-filter 系の除外に載せる(購読側で許されている場合)などドメイン単位の調整を検討します。
国内サイトだけ妙に遅い/海外だけ迂回しない
A. nameserver-policy が意図せず別上流へ向いていないか、IPv6 のみ別経路になっていないかを疑います。GEOIP ルールと DNS の組み合わせはGEOIP 記事のチェックリストがそのまま使えます。
ログに DNS 関連のエラーが増えた
A. upstream が DoH のときに社内フィルタと衝突している、時刻ずれで TLS ハンドシェイクが失敗している、listen アドレスが既に他プロセスに占有されている、などが典型です。エラー文字列をそのまま検索しつつ、listen と上流を一方だけ確実に動く組み合わせへ単純化してから段階的に戻します。
よくある質問(補足)
システムプロキシだけのときと TUN のときで DNS 検証は違いますか
A. 違います。TUN は OS のトラフィックキャプチャ経路が変わるため、クエリが Clash に届きやすい反面、競合ドライバの影響も受けやすいです。検証手順は同じでも、「届いていない」のではなく「キャプチャされていない」可能性を忘れないでください。
購読YAMLが fake-ip 前提のコメントでも redir-host で動きますか
A. 動くこともありますが、ルール設計がモード前提になっている場合は意図せず別グループへ滑ることがあります。プロバイダーの推奨がある場合は一度それに従い、自分で変えるなら本稿の検証をフルで回すのが安全です。
まとめ:モード選択は「目的」と「検証手順」のセット
Windows で Clash Verge Rev を運用するとき、dns.enhanced-mode の fake-ip と redir-host は、名前解決とルール評価の見え方と速度特性を変えるスイッチです。画面の版差に惑わされず、YAML の dns ブロックを軸に意味を把握し、切り替えたら名前解決・ブラウザ・ログの三本で必ずセルフチェックする——この型を覚えておけば、個別アプリのトラブルにも素早く横展開できます。
一方で、単体クライアントにDNS とルールの相互作用まで踏み込んだ日本語ドキュメントが薄いまま流通している例もあり、画面上のトグルだけ追うと fake-ip 固有の挙動や Windows のアダプタ設定とのズレで時間を溶かしがちです。オープンな Mihomo/Clash 系ではコミュニティの知見と検証手順が蓄積されており、記事群としてもモード別・GEOIP 別・ノード健全性別に読み分けやすいのが強みです。ClashSource ではその矢印を一本につなぐことを意識しており、本稿の手順を試したうえで総合ガイドや TUN 記事へ戻っても迷子になりにくい構成にしています。まだクライアント選びの途中であれば、ClashSource のダウンロードページから自分の環境向けのビルドを入手し、同じ検証チャートで fake-ip/redir-host を比較してみてください。Clash/Mihomo 互換クライアントを無料ダウンロードして試すだけでも、DNS モード変更の効き目が体感としてつかみやすくなります。