一、症状の整理：fake-ip っぽい挙動
fake-ip（拡張 DNS モードの一種）の典型的な動きは、ローカルでの名前解決の段階で、ルールに合うホスト名に対して仮想 IPv4（設定の fake-ip-range、例：198.18.0.1/16 付近の予約帯）を返すことです。実際の接続先は、カーネルやプロキシが接続を張るタイミングまで遅延して決まることが多く、多くのサイトでは体感が速くなります。一方で、特定のアプリやサイトが「一度仮想アドレスを受け取ったあと」でも独自の経路で再解決したり、証明書と SNI の整合を厳密に見たり、CDN のエッジ選択に DNS 結果を強く依存したりすると、ほんの数ドメインだけ不調という形に現れやすくなります。
セルフチェックの目安としては、ブラウザのアドレスバーが長く真っ白のまま、一部の金融・行政・社内ポータルだけがプロキシ有効時にだけ開かない、ゲームランチャーや会議アプリがネットワークエラーを出す、HTTPS でドメイン不一致の警告が出る、同じ PC でブラウザは普通なのに CLI だけ失敗する、といったパターンがあります。fake-ip をオフにして redir-host などへ切り替えるとすぐ直るのであれば、疑うべきは仮想アドレスの経路とフィルタ一覧であり、「ノードが死んでいる」単独説は後回しで構いません。
ルールの書き間違いと名前解決の問題を分けて考える点では、Perplexity まわりの分流ガイドでも触れた「分流だけ整えても DNS・DoH・fake-ip がズレると画面が進まない」という整理と同じ土台に立てます。まず名前解決の経路を疑い、次にルールやノードを見ると手戻りが減ります。
二、対照実験：fake-ip と強く相関しているか
大きな設定をいじる前に、最小の対照で因果を固定しておくと安全です。第一に、問題のホスト名について、クライアントのログや接続プレビューで返ってきたアドレスが fake-ip-range に入っているかを確認します。第二に、dns.enhanced-mode（利用コアの同等項目）を一時的に fake-ip から redir-host に変え、設定を再読み込みしたうえで同じ URL を開き直します。ここで症状が消えるなら、以降は fake-ip-filter と DNS に集中してよい、という判断ができます。
第三（任意）として、fake-ip のまま、テスト端末だけClash 外の DNSへ向けて比較する方法もあります。外に出すと直るなら、上流 DNS の到達性、奪取の順序、fallback の発火条件にボトルネックがありそうです。変化がなければ、ルール・ノード・スニッファ側の確認に戻ります。
三、fake-ip-filter：どのドメインを実 IP にするか
fake-ip-filter（テンプレによっては nameserver-policy と組み合わせて書かれることもあります）の役割は、一覧に載せたドメインには fake-ip を使わず、実際の A/AAAA 相当の結果を返すことです。ここに一行足りないだけで、そのホストはクライアントから見て常に「仮想アドレスのまま」になり、先述の互換性問題を踏みやすくなります。
filter に優先して入れたいタイプ
- LAN やプライベートなホスト名（
*.local、ルータ管理、NAS、プリンタ、社内ポータルなど）。仮想 IP では本来の L2/L3 の経路と一致しません。 - 証明書検証が厳しいサービス（一部のネットバンキング、決済、電子政府、ゼロトラスト VPN）。握手中に特定の解決経路やピンニングを前提にしていると、仮想 IP 経由で失敗しやすいです。
- 実エッジの選択に DNS を強く使う CDN。常に同じ仮想アドレスに見えると、極端な遅延や握手タイムアウトに見えることがあります（実装依存）。
- ルール上は DIRECT だが fake-ip のまま返しているドメイン。意味のずれが境界条件で噴きやすいので、該当ホストを
fake-ip-filterに入れておくと安定しやすいです。
設定例（フィールド名は利用コアのドキュメント優先）
以下は構造のイメージです。キー名は Mihomo / Meta 系の最新ドキュメントに合わせ、購読をマージするときは dns: ブロックの重複に注意してください。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.msftconnecttest.com"
- "stun.*.*"
- "+.srv.nintendo.net"
# 問題のホストを下に追加運用では、不調サイトの主ドメイン・ログイン遷移先・静的リソース・ WebSocket 用ホストを開発者ツールのネットワーク欄から拾い、まとめて filter に足してから DNS を再読み込みまたはコア再起動して再テストします。件数が増えてきたら geosite やルールセットでまとめ、例外だけ手で足すやり方も現実的です。
fake-ip-filter は広告ブロック用の巨大リストではありません。互換性のためのホワイトリストです。濫用すると fake-ip のメリットが薄れます。実際に壊れたドメインだけを足すのが筋です。
四、DNS：nameserver・fallback・解決の順序
fake-ip-filter が整っていても、DNS セクション自体が不安定だと「たまにだけ開かない」「モバイル回線だけ死ぬ」といった揺らぎが残ります。上流から順に見ていきましょう。
nameserver が届いているか
DoH / DoT / UDP の各 DNS が、今いるネットワークでブロックされていないかを確認します。企業 LAN やキャンパス、一部の ISP では非標準ポートや特定の DoH ホスト名が干渉され、断続的な解決失敗に見えます。別の上流へ一時的に切り替えて A/B すると、原因が DNS 側かどうかがはっきりします。
fallback と fallback-filter
主上流が汚染結果や異常値を返したときに fallback がちゃんと動くか、fallback-filter の geoip やドメイン条件が過剰でないかは、fake-ip 下でも誤った大陸・誤った回線の「前情報」を引きずる原因になります。テンプレから丸ごとコピーした激しめの filter は、公式例と突き合わせながら削るのがおすすめです。
nameserver-policy とドメイン別上流
国内向けと海外向けを混在させるプロファイルでは、nameserver-policy でサフィックスごとに上流を分けると、単一 DNS より安定することが多いです。これは WSL2 と Windows 側の DNS 記事で述べた「解決経路を層に分ける」考え方と同じで、クエリが正しい上流に届くかを先に満たしてから fake-ip の可否を議論すると筋が良くなります。
| 症状のイメージ | まず疑うところ |
|---|---|
| 特定ドメインだけおかしい | fake-ip-filter への追加漏れ、CNAME 連鎖がルールセットに入っていない |
| 場所や回線を変えると直る | DNS 上流のブロック・スロットル、DoH ホスト名の遮断 |
| 証明書エラーや SNI 系ログ | スニッファの誤検知、TUN 下で OS の証明書ポリシーと衝突（次節） |
五、スニッファと証明書：いつ狭める／止めるか
スニッファ（sniffer）は、暗号化後のトラフィックから TLS Client Hello などを手がかりにドメイン名を復元し、平文 Host が見えない場面でもルールを効かせるための仕組みです。fake-ip と同時に有効になっていることが多く、対象を広げすぎたり、特定サイトの握手実装と相性が悪いと、証明書警告、中間リセット、HTTP/2 や QUIC の挙動異常として現れることがあります。
切り分けのおすすめは、(1) ログで当該接続がスニッファ経由か確認する、(2) 必要なプロトコル・ポートにだけ範囲を狭める（例：TCP 443 のみ）、(3) それでも説明がつかなければ短時間オフで対照する、の順です。オフで直るなら、まずルールの絞り込みを検討し、安易に fake-ip 全体を捨てない方が全体体験は保ちやすいです。
デスクトップ GUI によっては「自動スニッファ」とシステムプロキシ／TUN が結びついているので、変更後はプロキシサービスや仮想 NIC の再起動まで含めて反映されているか確認してください。古いプロセスが前の挙動のまま残ると、設定を直しても再現がぶれる原因になります。
六、TUN・システムプロキシ・他クライアントとの併用
TUN モードと fake-ip を同時に使うと、OS のルート、既定 DNS、コア内部 DNS の間に循環に近い依存が生じることがあります。見た目は「fake-ip のせい」に似ていますが、実際にはルートの除外、bypass、DNS ハイジャックのオンオフ側の調整が近道になるケースがあります。TUN・ルート・ファイアウォールの記事で、まず TUN が全体断やループを起こしていないかを確認し、本稿の filter / DNS に戻ると筋が通ります。
同じマシンで別 VPN、企業セキュリティプロキシ、汎用「ブースター」系が動いていると、仮想アダプタの優先度争いで一部ドメインだけスタックがズレることもあります。問題アプリ側の「独自プロキシ」を切る、起動順を整理する、などで出口を一本化すると再現が止まることがあります。
長期運用では、「fake-ip-filter に入れたドメインと理由（証明書／社内／CDN など）」をメモしておくと、購読更新やクライアント乗り換えのたびに同じ穴を踏みにくくなります。
七、まとめ
Clash の fake-ip は多くの場面で接続開始を速くしますが、一部サイトだけが開かないときは、単一ノードの不調より fake-ip-filter の不足、DNS 上流と fallback の不安定さ、スニッファと TLS の重なりを疑った方が早いことが多いです。対照実験 → filter 補完 → DNS 確認 → スニッファを狭める → TUN 周りの整合という順で見ると、fake-ip を維持したまま局所修正しやすくなります。
毎回ネットの断片を探すより、異常ドメインを上のどれに当てはまるか分類してストックしておくと、プロファイルが育ちます。クライアントの入手と基本テンプレは ドキュメントから確認し、DNS セクションと fake-ip 周りを本文どおりに点検してみてください。
ルール・DNS・複数モードの組み合わせが文書化されている点では Clash 系は扱いやすく、仮想 IP と実解決の境界が腹落ちすると、ブラウザと開発ツールの両方で安定感が増します。