Clash Fake-IP モード徹底解説:Redir-Host との違いと適用シーン

DNS解析はプロキシ経路の中でどんな役割を担うのか

Fake-IPを論じる前に、見落とされがちな一点を整理しておく必要がある。クライアントがあるドメインにアクセスする際、まず本当のIPを解決してからどの経路を通すかを決めるのか、それとも逆なのか。この順序が、プロキシソフトの振り分け精度と応答速度を直接左右する。従来のOSのネットワークスタックは「先に解析、その後に接続」という順序を踏む——アプリケーションがシステムのDNS解析関数を呼び出して実IPを得て、そのIPでTCPやUDP接続を開始する。プロキシソフトがこの順序をそのまま踏襲すると、気まずい状況に陥る。ドメイン解析の段階ではまだプロキシを経由しておらず、ローカルネットワークのDNSサーバーにそのまま露出してしまう一方、後続の接続はプロキシのルールに基づいて振り分け判定を行わなければならないからだ。

Clashコア(Clash PremiumおよびClash Meta/mihomoを含む)のルールマッチングでは、多くのルールタイプがドメインベースで設計されている。例えばDOMAIN-SUFFIX、DOMAIN-KEYWORDだ。この種のルールは接続開始の段階でマッチングが完了し、IPに依存しない。しかしIPに依存するルールもある。例えばGEOIP、IP-CIDRで、これらのルールはクライアントが振り分け判定を行う前に、必ず使用可能なIPアドレスを取得している必要がある。ここで矛盾が生じる——通常の流れに従って先に本物のDNS解析を行えば、解析リクエスト自体がローカルの通信事業者やLAN内のDNSサーバーに漏洩する可能性がある。これがいわゆるDNS漏洩だ。逆に一切解析を行わずドメインをそのままリモートのプロキシノードに渡すと、IPベースのローカルルールが機能しなくなる。Fake-IPはまさにこの両者の間で折り合いを取るために設計された仕組みだ。

Fake-IPはどのように仮アドレスで速度とプライバシーを両立させるのか

Fake-IPの核心的な発想は一言で言える。クライアントがローカルで「ドメイン→仮IP」のマッピングテーブルを管理し、アプリケーションがあるドメインの解析をリクエストすると、Clashコアは公開DNSに実際に問い合わせるのではなく、予約されたプライベートアドレス帯(通常は198.18.0.0/16)から未使用のアドレスを一つ割り当てて、そのままアプリケーションに返す。アプリケーションは見た目上正常なこのIPを受け取り、通常どおり接続を開始する。パケットはローカルのルーティングやTUN仮想NICによって捕捉され、コアはこの仮IPから対応する元のドメインを逆引きし、そのドメインをリモートのプロキシノードに渡して、実際のDNS解析と接続をそこで行わせる。

この流れがもたらす第一の利点は速度だ。アプリケーションが仮IPを受け取るのはほぼゼロレイテンシのローカル操作であり、実際のネットワーク往復を待つ必要がないため、初回接続確立までの待ち時間が大幅に短縮される。第二の利点はプライバシーだ。ローカルのネットワーク環境からは、ユーザーが実際にアクセスしているドメインに対応する真のIPが何であるかが一切見えず、DNSクエリもローカルネットワークの解析サーバーへ実際に送信されないため、DNSレベルでの情報露出が減る。第三の利点はルールの互換性だ。各仮IPは元のドメインへ一意に逆引きできるため、ドメインベースのルールはローカルで通常どおりマッチングを完了でき、リモートの解析結果を待つ必要がない。

典型的なFake-IPのDNS設定構成はおおむね以下のようになる(mihomoコアを例に):

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'time.*.com'
    - 'ntp.*.com'
    - '+.push.apple.com'
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query

ここでenhanced-mode: fake-ipはFake-IP強化解析モードの有効化を明示し、fake-ip-rangeは仮アドレスプールのアドレス帯を定める。そしてfake-ip-filterは、どのドメインをFake-IPの対象外として実際の解析結果を使うかを決める重要な設定項目であり、後段でその必要性について詳しく説明する。

Fake-IPとRedir-Hostの本質的な違い

Fake-IPが登場する前、Clashエコシステムでより早くから広く使われていたのはRedir-Hostモードだ。両者はいずれも「拡張DNSモード」(enhanced-mode)の設定値の一つだが、動作方式は完全に異なる。この違いを理解することは、どのシーンでどちらを使うべきかを判断するのに役立つ。

• Redir-Hostの方式:クライアントはDNSリクエストを受けると、実際にアップストリームサーバーへ解析を要求して真のIPを取得し、それをそのままアプリケーションに返す。ルールマッチングは主に後続のトラフィックリダイレクト段階でのドメイン記録に基づいて判定され、接続確立時には真のIPが使われる。
• Fake-IPの方式:前述のとおり、実際の解析を行わず仮アドレスを直接返し、真の解析は接続が実際に確立されトラフィックがプロキシノードに入った後、リモート側で行われる。

この違いは実際に体感できるいくつかの差異をもたらす。まず速度について。Redir-Hostは毎回の解析で実際のDNS往復を待つ必要があるが、Fake-IPはこのステップを省くため初回接続の速度が速く、特に海外接続の環境では体感差が明確だ。次にプライバシーの境界について。Redir-Hostモードでは、端末は依然として真のドメインをアップストリームDNSサーバーに渡して解析させる。そのアップストリームが信頼できる暗号化DNSであっても、解析記録はローカルネットワークの出口を経由する。一方Fake-IPは解析のステップを完全にプロキシノードの後段へ移すため、ローカルネットワークからは真のドメインに対応する解析行為が一切見えない。第三に互換性について。「アプリケーション層が直接真のIPを取得する」ことに依存する一部のシーン(たとえば一部のゲームクライアントがサーバーIPを接続品質検知に使う、あるいは一部のNAT越えツールが真のアドレスによる検証を必要とする)では、Fake-IPだと異常が出る可能性がある。アプリケーションが常に受け取るのは仮アドレスであるためだ。Redir-Hostは少なくともアプリケーション層が見るIPが真のものであることを保証できる。

そのため、現段階の主流クライアント(mihomoコアをベースとする各種GUIクライアントを含む)はデフォルトでFake-IPの使用を推奨し、Redir-Hostは互換性問題への代替手段として残す位置付けとなっており、逆ではない。使用中に特定のアプリで接続異常、アドレス表示の乱れ、ハンドシェイク失敗が見られた場合は、まずFake-IPの仕組みによって真のIPが見えなくなっていることが原因かを確認し、その上で一時的にRedir-Hostへ切り替えて切り分けを検討するとよい。

fake-ip-filterを正しく設定する必要がある理由

Fake-IPは速度とプライバシーの両方で利点をもたらすが、すべてのドメインに適するわけではない。アプリケーションが正常に動作するために真のIPを必要とするドメインのシーンも存在し、この場合は必ずそれらをfake-ip-filterのリストに追加して、Fake-IPロジックをスキップし実際の解析を行わせる必要がある。

LANおよび社内ネットワークのサービス

自宅や社内のネットワークにドメインでアクセスするNAS、ルーター管理画面、NAT越えサービスなどがある場合、これらのドメインが解析すべきなのはLAN内の真のIPであり、仮アドレスであってはならない——そうでなければ、機器がLAN内の実際のホストを特定できなくなる。よくある対処法は、*.lan、*.localおよび独自のイントラネットドメインサフィックスをまとめてフィルターリストに追加することだ。一部の企業のイントラネットでは自前のドメインをプライベートアドレス帯に解析させることもあり、この種のドメインもフィルター対象に含めるべきだ。

時刻同期と低遅延検知サービス

OSの時刻同期プロトコル(NTP)は通常プロキシ転送に依存せず直接IP通信を行うため、Fake-IPに引き受けられてしまうと、逆に時刻同期の失敗や遅延異常を招くことがある。同様に一部のシステムレベルのネットワーク品質検知サービスも、これらのリクエスト自体はプロキシを経由する必要がなく、仮アドレスに干渉されるのも望ましくない。そのため一般的な設定テンプレートにはntp.*.com、time.*.comといったルールが事前に組み込まれていることが多い。

プッシュサービスとリアルタイム通信

一部のOSレベルのプッシュ通路(たとえば端末とベンダーのプッシュサーバー間で維持される持続接続)は、接続の安定性と真のアドレスに対する要求が高く、Fake-IPに引き受けられるとプッシュの遅延や切断が発生する可能性がある。設定テンプレートによく見られる+.push.apple.comのようなワイルドカードルールは、こうした状況を避けるために存在する。

ゲームプラットフォームとリアルタイム対戦サービス

一部のオンラインゲームクライアントは、サーバーへの接続前に目的IPへ能動的なネットワーク品質検知を行ったり、ゲーム内でサーバーの真の遅延やアドレス情報を表示したりする。このようなシーンでアプリケーション層が受け取るのが仮IPだと、検知結果が歪んだり、ゲームクライアント自身が異常な接続と判定してしまうことすらある。接続異常やマッチング失敗が頻発するゲームプラットフォームのドメインについては、まずfake-ip-filterに追加して問題が解消するか観察し、その後そのゲーム専用の振り分けルールを個別に作るかどうかを判断するとよい。

実際の利用でよくある疑問と切り分けの考え方

Fake-IPを有効化した後、一見奇妙に見える現象に遭遇するユーザーもいる。ここでは典型的なケースといくつかの切り分けの方向性を挙げる。

一部のアプリに表示されるサーバーIPが198.18で始まる見慣れないアドレスなのはなぜか

これはまさにFake-IPのアドレス帯が働いている証拠だ——アプリケーションの接続情報に198.18.x.xのようなアドレスが表示されていれば、通常はその接続がFake-IPに引き受けられ、ドメイン解析の結果が仮アドレスであり真のIPではないことを示している。これ自体は正常な現象であり、当該アプリで機能上の異常が出ていない限り、設定ミスを意味するものではない。

ネットワークを切り替えた後、アドレスのマッピングをクリアする必要があるか

Fake-IPのマッピングテーブルはクライアントのローカルで管理されており、通常はプロセスの再起動や手動でのDNSキャッシュクリアによってリセットされる。ネットワーク環境を切り替えた後に接続異常が出た場合は、クライアントの画面で「Fake-IPキャッシュのクリア」や類似の項目を探してみるとよい。一部のGUIクライアントはこの操作をDNS設定や高度な設定のセクションに置いている。

IPv6環境で注意すべき点

Fake-IPはデフォルトのシナリオでは主にIPv4のアドレスプールをカバーしている。ローカルネットワークで同時にIPv6が有効になっており、システムがIPv6接続を優先的に試みる場合、一部のトラフィックがFake-IPロジックを回避して直接IPv6接続を開始してしまう可能性がある。多くの設定テンプレートではDNS設定のipv6項目を明示的にfalseにするか、ルールセットと組み合わせてIPv6トラフィックを個別に処理することで、プロキシ判定を回避する接続経路が生じるのを防いでいる。

DNS漏洩が改善されたかどうかをどう検証するか

DNS解析の出所を確認できるオンライン検知ツールを使い、Fake-IPを有効化する前後でそれぞれ一度検知して、解析記録の帰属地に変化があるかを比較するとよい。正常な状況では、Fake-IPを有効にし信頼できるリモートDNS解析と組み合わせた場合、検知結果はプロキシノードが所在するネットワークで解析が行われていることを示すべきで、ローカルの通信事業者のDNSサーバーではないはずだ。

Fake-IPとTUNモードの連携関係

Fake-IPはよくTUNモードと一緒に語られるが、両者が解決するのは異なる次元の問題であり、混同してはならない。TUNモードはシステムのネットワーク層に仮想NICを一つ立て、すべての送信トラフィック(ブラウザや個別アプリだけでなく)がClashコアを経由するようにする仕組みで、これが解決するのは「どのトラフィックをプロキシの対象に含められるか」というカバレッジの問題だ。一方Fake-IPが解決するのは「ドメイン解析のステップをどう処理するか」という問題であり、両者は独立して有効化することもできるし、同時に使用することもできる。実際の設定では、TUNモードを有効化した際に併せてFake-IPの有効化も推奨されることが多い。それによってTUN仮想NICが捕捉するトラフィックがドメインルールのマッチング段階で十分な情報を得られ、同時にシステムレベルのDNSリクエストが仮想NICを回避して直接ローカルネットワークへ送信されるのを防ぎ、閉じた完全な流れが形成されるからだ。

TUNモードだけを有効化してDNS強化モードが未設定のまま、あるいはシステムデフォルトの解析を使っている場合、DNSリクエストがプロキシを回避して本機に設定されたDNSサーバーへ直接送信されてしまうケースが依然として起こり得る。これは「TUNモードは有効なのに解析失敗やDNS漏洩が表示される」という問題を切り分ける際、最初に確認すべき設定項目だ。

設定に関する提案のまとめ

以上の仕組みを踏まえ、実際にそのまま適用できるいくつかの提案を示す。特別なイントラネットの要件がない一般ユーザーは、クライアントのデフォルトのFake-IP設定をそのまま維持すればよく、追加の調整は不要だ。イントラネットのサービスや企業内ドメイン解析の要件があるユーザーは、fake-ip-filterリストを能動的に確認・補完し、イントラネットのドメインサフィックスを追加すべきだ。ゲームやリアルタイム通信系アプリで接続異常が発生した場合は、まずFake-IPの影響を疑い、該当ドメインを一時的にフィルターに入れるか、Redir-Hostに切り替えて比較テストを行うことで問題を特定するとよい。TUNモードを有効化しているユーザーは、DNS強化モードとFake-IPのアドレス帯設定が確実に連動して有効になっていることを確認し、トラフィックは捕捉されているのに解析が本機デフォルトのDNSを経由してしまう中途半端な設定状態にならないよう注意すべきだ。