Clash Meta で DNS は fake-ip と redir-host どちら？分流が効かないときの対照と修正手順（2026）

1. fake-ip と redir-host が変えるもの

端的に言えば、どちらも アプリケーションが名前解決したときに返ってくる IP の見え方と、その後コアが実際の接続先を決める経路が異なります。fake-ip はプライベート帯などの「コアが割り当てた仮アドレス」を先に返し、接続時にドメイン情報とひも付けてルール評価しやすくする設計です。redir-host はアプリが見る結果を「できるだけ実ホスト寄り」に保ちつつ、DNS の問い合わせ経路をコア側で整理するイメージです（実装とバージョンで細部は変わるため、必ず手元のログで確認してください）。

ここで誤解されやすいのは、「モードを変えれば速度や暗号が変わる」という話ではない、という点です。変わるのは主に どの段階でドメインと IP がルールエンジンに渡るかと、キャッシュやフィルタと組み合わせたときの一貫性です。分流ルールがドメイン前提なら、その名前が評価パイプラインのどこで効くかを意識しないと、画面上は「ちゃんと開ける」のに策略だけズレる、という状態が残ります。

2. モード別の流れ（対照表）

以下は概念整理用の対照です。環境やテンプレート名によって YAML のキー配置は異なるので、そのままコピペではなく読み替え表として使ってください。

実務ではどちらが絶対優れているより、購読テンプレート・クライアント既定・LAN 機器の有無でトータルが安定する方を選ぶのが現実的です。

3. どちらを選ぶか：現場の判断軸

fake-ip を優先しがちなケースは、GEOSITE／DOMAIN ベースの細かい分流が多く、HTTPS でドメインをルールに載せたいときです。一方で、ゲームランチャーや一部アプリが「解決結果の IP」を独自判定に使う場合、仮 IP と相性が悪いことがあります。そのときは fake-ip-filter で対象を実解決寄りに除外するか、モード自体を見直す判断になります。

redir-host を選ぶ理由が厚くなるケースは、ブラウザや OS の「安全な DNS（DoH）」が並走していて二重解決が起きやすいときです。Windows でブラウザだけ挙動がおかしいときの OS／ブラウザ側の切り分けは、Windows での Secure DNS とシステム代理の稿とセットで読むと線が繋がります。mihomo は設定の表現力が高いぶん、DNS モード・listen・fallback・nameserver-policyを同時にいじると差分が見えにくいので、変更は一項目ずつが安全です。

4. 分流がおかしくなる典型パターンと原因

ユーザーから見えやすい症状は次のようなものです。サイトは開けるが国内外どちらへも期待どおりに振られない、国内サイトなのにプロキシへ載る／その逆、ルールを足してもログのマッチが変わらない。原因は一つではなく、代表的には（1）ルールより先に GEOIP／IP-CIDR が勝っている、（2）DNS がコア外で先に解決してしまい名前がルールに渡っていない、（3）HTTPS が IP のまま評価されドメインルールに届かない、の三層に分けて整理すると切り分けが早いです。（3）は TLS の SNI が絡むので、Sniffer とログで SNI を確認する稿が続きです。

DNS モードをまたいで共通して言えるのは、「開く／開かない」は通信経路の一部だけを見た結果で、「どのルールにマッチしたか」は別問題だということです。だからこそ、設定を増やす前に debug ログで実際のマッチ名とアウトバウンドを一行ずつ確定させます。

5. 修正手順：ログで事実を取ってから設定を動かす

推奨の順序は次のとおりです。（1）問題のサイトだけを再現し、log-level: debug で短時間ログを取得する。（2）その接続について DNS クエリ→返答→ルール名→実際のアウトバウンドが時系列で追えるか確認する。（3）ズレているのが DNS かルール順か HTTPS の名前解決かを切り分ける。（4）モード変更・nameserver-policy・fake-ip-filter・ルール順のどれを触るかを一つに絞る。（5）変更後もう一度同じ手順でログ検証する。

# config.yaml fragment — temporary debug (revert after troubleshooting)
log-level: debug

fake-ip 利用時は、例外ドメインがフィルタから漏れていないかを定期点検してください。逆に redir-host では、上流 DNS がどこか（ISP・DoH・コア内）をログと設定ファイルの両方で一致させます。購読そのものの TLS／名前解決トラブルは別筋ですが、切り分けの癖は 購読更新とログの稿とも共通です。

GUI（例：Clash Verge Rev）を使う場合も、考え方は同じです。画面上の策略名とログのルール名が同一か、有効プロファイルが一本かを最初に確認してください。複数プロファイルを切り替えていると、「ファイルは直したつもりが実行中は別」という事故が残りやすいです。

6. fake-ip-filter・nameserver-policy・Sniffer との関係

fake-ip-filter は「この名前は仮 IP で返さず実解決寄りにしたい」という逃げ道です。LAN の名前、キャプティブポータル、ストア系などテンプレートに例が載っていることが多いですが、自分の環境だけ別ドメインが要る場合はログから追加します。nameserver-policy はドメインごとに DNS を分ける仕組みで、海外サービスだけパブリック DNS、国内だけ ISP、といった名前の出どころを揃えるのに効きます。DNS モードとセットで設計しないと、また分流が二度手になります。

HTTPS が絡むドメイン分流で接続が IP のままルールに入る場合は、DNS の話だけでは足りず、Sniffer が TLS の SNI を復元してドメインルールへ橋渡しする、というレイヤーになります。本稿が DNS モードの土台なら、Sniffer 稿はその上のレイヤーだと捉えると迷いにくいです。初手の全体像は チュートリアル総覧にもまとまっています。

7. まとめ

Clash Meta／mihomo の DNS fake-ip と redir-hostは、「名前と IP がルール評価にどう載るか」を変えるスイッチです。ページが開けることだけを見て設定成功とみなすと、分流や地域判定のズレが残りがちです。debug ログで DNS とマッチしたルールを揃えてからフィルタやポリシーを足すと、変更理由が説明できるので運用も楽になります。

同種のツールのなかでも Clash 系はルール表現とログの両方を読みやすく、トラブル時に観測しながら直せるという意味で再現性が高い部類です。まずは短時間だけログを丁寧に取り、ボトルネックを一つに絞ってから設定を変えてください。

クライアントの入手と環境別の導線は → 無料で Clash をダウンロードし、快適な接続体験を試す からどうぞ。