なぜ「DNSモード」がローカルや一部サイトの成否に効くのか
プロキシのルールは多くの場合「ドメイン名」か「IP アドレス」で分岐します。ここで Clash Fake-IP を使うと、アプリケーションが最初に受け取る IP はしばしば「実際のサーバー」ではなく、Clash が割り当てた仮想アドレスになります。そのおかげで「名前解決の段階でどのポリシーに乗せるか」をコア側で握りやすくなり、分流が安定しやすい反面、アプリや OS が返ってきた IP をそのまま信用して二次接続するような特殊なケースでは齟齬が出ます。
一方 Redir-Host は、ざっくり言えば「実名解決の結果を尊重しつつトラフィックを転送する」方向の挙動であり、イントラネット の名前や .local、社内 DNS にだけ載っているホストなど、ローカル寄りの名前解決とは相性が良いことが多いです。ただし上流の解決経路やキャッシュ、ルールの書き方次第では、意図せず遠隔 DNS に聞きに行ってしまい 解析失敗 や遅延が増えることもあります。つまり「正しい／誤り」より、環境に合わせた選択と、その後の切り分け手順が重要です。
Fake-IP と Redir-Host：体感として何が変わるか
fake-ip では、多くのクライアント設定で指定されたレンジ（例：198.18.0.1/16 付近）から応答が返ることがあります。ブラウザやアプリはそのアドレスへ接続しようとし、実際の転送先は Clash が元のドメインとルールから決めます。ルールが DOMAIN ベースで揃っているほど快適ですが、解決結果の IP を前提にしたアプリ や、同一ホストに対して別経路で再度解決し直す実装があると、期待とズレることがあります。
redir-host では、実アドレス（または上流から返った答え）を踏まえて転送が組み立てられやすく、社内ファイルサーバやプリンタ、検証用の hosts エントリなど、ローカルドメイン をそのまま使いたい場面では試しやすいです。代わりに、GEOIP や IP-CIDR へのフォールバックが早まる一方で、DNS 汚染や遅い上流、誤ったキャッシュの影響をダイレクトに受けやすい、という側面もあります。
実装差に注意してください。Clash Meta（mihomo） 系では項目名やデフォルト、付随する fake-ip-filter や nameserver-policy の効き方がバージョンで微調整されることがあります。細部は利用中のコアのドキュメントに合わせるのが安全です。コア更新の全体像は コア更新ガイド を参照してください。
どちらを選ぶか：簡易な判断基準
まずは次のような優先度で考えると迷いにくいです。社内 VPN・イントラのホスト名・mDNS（.local）を頻繁に使うなら、初期候補は redir-host 側（またはそれに近い挙動へ寄せる設定）に寄せ、必要なドメインだけ上流やポリシーを細かく切ります。逆に、購読ルールが DOMAIN ベースで厚く、ストリーミングや海外 SaaS の出口を安定させたいデスクトップ用途では fake-ip の方が運用しやすいことが多いです。
「両方の良いとこ取り」をしたい場合は、モードを頻繁に行き来するより、例外リスト と 名前解決ポリシー で局所調整する方が再現性が高いです。代表例として、社内サフィックスだけシステム DNS／社内 DNS に投げ、それ以外は Clash 側の名前解決に任せる、という住み分けが効きます。分流ルールの書き方全般は YAML ルール分流ガイド とセットで整理すると頭の中の地図がつながります。
切り分け1：症状が「全体的」か「特定ドメインだけ」か
まずは観測を言語化します。ブラウザがまったく開かない、全アプリがダメ、というなら DNS モード以前に TUN／システムプロキシ、他 VPN、ファイアウォール を疑った方が早いです。TUN を使っている場合は、仮想アダプタや権限まわりも絡みます。デスクトップでの典型例は TUN とシステムプロキシの解説 にまとめています。
一方で「Google は開くが社内ポータルだけ開かない」「*.example.corp だけタイムアウト」「特定の国内 CDN だけ変」といった スコープが狭い 症状は、DNS モードと nameserver の選択、および DIRECT ルールの取り違えが疑わしいです。この段階でいきなりサーバ名を変えたり購読を捨てたりせず、再現手順を固定してください。
切り分け2：モードを一時的に切り替えて再現性を見る
バックアップを取ったうえで、fake-ip と redir-host を入れ替えて同じ URL を開き直します。挙動が劇的に変わるなら、原因のかなりの部分が 名前解決とコアの DNS 実装の組み合わせ に集中しているサインです。変わらないなら、ルールで DIRECT になっているか、TLS の SNI、キャッシュ、別プロキシの干渉など、DNS 以外の層を並行して疑ってください。
切り替え試験は「直ちに本番設定にする」ためではなく、観測のための一時作業です。結果が出たら、なぜそのモードで安定したのか（例：ローカル向けを実解決できた、DOMAIN ルールに乗るようになった 等）をメモし、恒久対策として fake-ip-filter や nameserver-policy、ドメイン単位の DIRECT に落とし込みます。
切り分け3：ローカル・内網・社内サフィックスの例外を整える
fake-ip 利用時にローカル系が壊れやすい場合、代表的な対処は フィルタにローカル帯や社内ドメインを入れて実解決に回す ことです。プライベート IP レンジ、社内の検証用 TLD、社給のサブドメインなど、パターン化できるものはルールより先に DNS 側の例外として整理するとメンテナンスが楽になります。
社内 DNS サーバへ到達する経路そのものがプロキシ越しになると、逆に解決が失敗することがあります。イントラの名前解決は DIRECT で上流のリゾルバに届くようにし、不要な TLS インタセプトや誤った DoH エンドポイント指定が入っていないかも確認してください。ここは環境差が大きいので、「社内 DNS の IP がプロキシを経由していないか」を traceroute やクライアントの接続ログで一度見る価値があります。
切り分け4：上流 DNS（DoH／DoT／UDP）を対照実験する
モードを変えても特定ドメインだけ失敗するときは、上流のリゾルバがブロックされている、応答が遅すぎる、ECS や EDNS の扱いで変なフォールバックをしている、などの可能性があります。一時的に別のパブリック DNS、あるいは ISP 提供の DNS に切り替えて比較してください。社内ネットワークでは外部 DoH が禁止されていることも多いので、その場合は 許可された社内リゾルバ に合わせるのが先です。
複数の nameserver を並べている場合、フォールバック順とタイムアウト設定によっては「最初のサーバが微妙に失敗→全体が遅い」ことがあります。ログでどのクエリがどのサーバに飛んでいるかが分かるクライアントなら、そこを手掛かりにします。
切り分け5：ルールと「実際の接続先」の取り違い
名前は解決できてもページが白紙、証明書エラー、一部リソースだけ落ちる場合は、DNS 以外の層です。SNI が期待と違う、HTTP/3 だけ別経路、広告ブロック系ルールが誤爆、といったケースはログを見ないと見落としがちです。とはいえ、fake-ip で取得した擬似 IP をアプリがキャッシュし続ける と、ルール変更後も古い経路に残ることがあります。ブラウザの DNS キャッシュ、アプリの再起動、OS の再起動も対照実験に含めてください。
国内サイトだけ遅い／開かないとき、GEOIP や国別リストの更新タイミング、CDN のエッジ選択、IPv6 の経路差も絡みます。IPv4 のみに固定して試す、別ブラウザで試す、といった素朴な切り分けが意外と効きます。
設定のたたき台（概念メモ）
実際のキー名は利用コアのスキーマに合わせてください。概念としては次のような整理がよく使われます。enhanced-mode に fake-ip か redir-host を指定し、fake-ip-filter にローカル／社内向けのドメインや IP を足す。nameserver-policy でサフィックスごとにリゾルバを分ける。fallback 群を用意しつつ、イントラ向けはフォールバック連鎖に入れない、などです。
# Illustrative YAML fragment — adjust keys to your core version
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1
fake-ip-filter:
- "*.lan"
- "*.corp.example.com"
nameserver-policy:
"corp.example.com": system
この断片は動作保証のある完成形ではなく、どこを触るとローカル例外が作れるか のメモです。購読プロバイダの巨大な既定 DNS ブロックがある場合は、上書き順とマージ結果にも注意してください。
チェックリスト早見表
| 症状の手がかり | まず見る場所 |
|---|---|
| 社内ホスト・.local だけ不通 | redir-host への寄せ、fake-ip-filter、DIRECT、社内 DNS 到達性 |
| ルールは合っているのに経路がズレる | 擬似 IP のキャッシュ、アプリの独自解決、ブラウザの DNS キャッシュ |
| 特定ドメインだけ遅い／失敗 | 上流 DNS、DoH ブロック、フォールバック順、IPv6 |
| モード変更で一気に改善 | 名前解決と DOMAIN ルールの噛み合わせを再設計 |
まとめ
Clash Fake-IP と Redir-Host の選択は、分流のしやすさと ローカルドメイン／内網アクセス の互換性のトレードオフです。開かない事象が出たら、全体不通か一部ドメインかを切り分け、モードの A/B 試験で DNS 層の寄与を測り、例外と nameserver の住み分けへ落とし込むのが実務的です。Android 端末での広い範囲の接続異常は 既存の seven-step 記事 が土台になり、本稿はデスクトップ寄りの DNS モード 判断にフォーカスしています。
クライアントの入手経路が整理されていると、端末や職場環境が変わっても同じ手順で試行錯誤を再開しやすくなります。GUI 付き製品とヘッドレス運用のどちらでも、コアの挙動の芯は共通です。
ほかのチュートリアルは 技術コラム からどうぞ。