こんな症状のときに読む記事です

ダッシュボードでは遅延テストが通り、チャットや動画も問題なく動くのに、特定の Web サイトだけがずっと読み込み中のまま、あるいは真っ白で進まない——Clash／Mihomo（Clash Meta コア）を使っていると、この手の「一部だけおかしい」現象に出くわすことがあります。原因は一つではなく、名前解決の経路、TLS などからホスト名を推測する Sniffer、ルールとポリシーの優先順位が重なった結果として表れることがほとんどです。

本記事では、まず dns.enhanced-mode にある fake-ip と redir-host の役割の違いを整理し、そのうえで「Sniffer を切るべきか」「DNS モードを替えるべきか」「ルールを直すべきか」を、チェックリスト形式の故障ツリーに沿って説明します。プライバシー寄りの DNS 設計全般は DNS 漏洩防止ガイド、ログの読み方は ログ診断の記事 とあわせて参照すると、切り分けがさらに速くなります。

DNS モード：fake-ip と redir-host は何が違うか

Mihomo では dns.enable: true と組み合わせて enhanced-mode を指定し、ルールエンジンが接続先を判断するまでの「名前解決の見え方」を制御します。ここが誤解されやすいので、ユーザーが体感しやすい言葉で押さえておきます。

fake-ip（仮想 IP を返す）

クライアントアプリにはプライベートレンジなどの「仮の IP」が返り、実際の接続フェーズでコアが改めて本物のアドレスへ解決し直す流れです。ルールがドメイン基準で書かれている構成と相性がよく、体感では応答が速く感じられることが多いモードです。一方で、fake-ip-filter に載せるドメインの選び方を誤ると、意図せず実アドレス解決のタイミングがずれ、特定サービスだけが開かない原因になります。LAN 名、キャプティブポータル、一部の P2P／STUN 系、銀行アプリが参照するドメインなどは、フィルタに入れる例がよく挙げられます。

redir-host（実 IP を返す）

上流 DNS から得た実在アドレスを（ポリシーに応じて）返す方向の挙動です。古いアプリケーションや、接続先 IP を厳密に検証するタイプの通信と相性がよい場面があります。ただし解決結果がそのまま観測ポイントに触れやすい構造でもあるため、上流を信頼できる暗号化 DNS に寄せる前提が重要です。詳細なスタック設計は前述の 漏洩防止ガイド の nameserver／fallback の章とセットで読むと理解が早いです。

ポイント：どちらが「正解」というより、利用アプリ・購読ルール・TUN の有無の組み合わせで最適解が変わります。症状が出たら、まず「DNS だけの問題か」「ルーティングだけの問題か」を分離して考えると迷いが減ります。

故障ツリー：上から順に試す

以下は、実務で再現性が高い順序です。すべてを一度にいじらず、一ステップごとに挙動を確認してください。

  1. ステップ 1 — 再現範囲の確認：同じ URL を別ブラウザ・シークレット・別端末で試す。全体がダメならノードやローカルポートを疑い、一部ドメインだけなら DNS／Sniffer／ドメインルールを疑う。
  2. ステップ 2 — システム DNS とブラウザのセキュア DNS：OS の DNS が Clash の仮想スタックを素通りしていないか、Chrome などの「DNS over HTTPS」が二重になっていないかを確認する。
  3. ステップ 3 — Sniffer の切り分け：fake-ip 利用時に、TLS の SNI などからホスト名を復元する Sniffer が有効だと、誤ったホスト名推定により DIRECT や意図しないグループへ振られることがあります。一旦オフ、または対象プロトコル／スニッフィング対象を絞って比較する。
  4. ステップ 4 — fake-ip-filter とドメインルール：問題のドメインをフィルタに追加する、あるいは DOMAIN／DOMAIN-SUFFIX ルールをポリシーの手前で明示する。購読ルールが IP-CIDR 先行だと、fake-ip 段階では想定とズレる場合がある。
  5. ステップ 5 — enhanced-mode の切替：上記で改善しないとき、試験的に redir-host へ切り替え、同じ URL で再現するか見る。改善するなら、fake-ip と Sniffer／ルールの組み合わせが原因だった可能性が高い。
  6. ステップ 6 — TUN と dns-hijack：プロキシを無視するアプリがいる環境では、TUN と dns-hijack でクエリをコアに集約する。Windows の管理者権限、macOS の拡張承認など前提を満たしているかも併せて確認する。

ログに dial tcp のタイムアウトやポートの bind 失敗が並んでいる場合は、DNS 以前の層の可能性が高いです。そのときは ログ診断ガイド のキーワード一覧に立ち返ってください。

Sniffer をいつ疑うか

fake-ip モードでは、接続開始時点ではまだ「本当のドメイン」と「ルールが参照すべきホスト名」の対応がコア内部で完結しています。ここに Sniffer が介入し、TLS Client Hello の SNI や HTTP ホストから名前を推測してルール評価を補うことがあります。これは便利な反面、中間機器や分割 TLS、非標準なクライアントでは推測が外れ、見かけ上は接続しているのにコンテンツが返らないという症状に見えることがあります。

切り分けとしては、(1) Sniffer を一時的に無効化して同じサイトを開く、(2) 有効のまま対象を絞る、(3) 問題ドメインだけルールで明示的にプロキシグループへ送る、のいずれかから試すのが現実的です。改善したら、本番設定では「必要最小限のスニッフィング」に落とし込みます。セキュリティポリシー上 Sniffer を常時オンにできない環境では、最初から redir-host 寄りの構成を検討する価値があります。

ルールとポリシー：モードを変える前に見る場所

「DNS モードが悪い」と決めつける前に、次の三点を確認してください。ここがずれていると、fake-ip と redir-host を何度切り替えても改善しません。

  • ルールの順序：より具体的な DOMAIN 行が、広い MATCH や地理系ルールより上にあるか。
  • ポリシーグループの実体：選択中のノードが本当にそのドメインに到達できるか（別アプリでは通るがブラウザだけ失敗、は DNS／証明書／拡張の線もあり得る）。
  • 分流ルールと DNS の整合：ドメインをプロキシへ送っているのに、解決だけローカル DNS に落ちているパターンは、enhanced-mode や TUN の設定とセットで直す必要があります。

ルールプロバイダの更新タイミングや、地理データの世代が古いことで誤マッチするケースもあります。設定の全体像は ドキュメント のルール章と併せて確認すると、購読テンプレートの意図を読み解きやすくなります。

いつ redir-host 側に寄せるか

次のような信号が出たら、試験的に redir-host へ寄せる候補です。(1) Sniffer をオフにすると安定するが、オンにすると特定サイトだけ不安定になる。(2) fake-ip-filter を増やしすぎると運用が破綻しそうなほど例外ドメインが多い。(3) 社内アプリやレガシー HTTP クライアントが fake-ip と相性悪い。(4) セキュリティツールが TLS を検査し、SNI ベースの推測が信頼できない。

逆に、レイテンシやルールの明快さを優先し、フィルタと Sniffer を調整したうえで fake-ip を使い続ける構成も十分にありえます。大事なのは、再現手順とログ行をセットで記録し、一度に一変数だけ変えることです。

まとめ：モード選択は「切り分けの結果」で決める

ノードは生きているのにページが開かない問題は、DNS の enhanced-mode、Sniffer、ルールの三層に分けて考えると道筋がつきます。fake-ip は速く扱いやすい反面、フィルタと Sniffer の設計ミスが特定ドメインの不調に直結しやすい。redir-host は実解決に寄り、一部アプリとの相性はよいが、上流 DNS の信頼性と漏洩対策を別途固める必要があります。この記事の故障ツリーを上から順に試し、ログとブラウザの挙動を突き合わせれば、「Sniffer を切る」「モードを替える」「ルールを足す」のどれが効くかが見えてきます。

GUI 付きクライアントでは、コアのバージョンと DNS パネルの表示が一致しているかも確認ポイントです。ソースや Issue 追跡は GitHub が適していますが、日々のインストールと更新はパッケージが整理された公式の入手ページに寄せた方が、設定試行錯誤のループ自体が短くなります。関連トピックは 技術ブログの一覧 から辿れます。→ Clash を無料ダウンロードして、fake-ip／redir-host の切り分けを手元の環境で試す