#Fake-IPモード徹底解説:DNS応答の仕組み・メリットとデメリット・fake-ip-filter設定

なぜDNSモードは選択が必要になるのか

通常のネットワーク環境では、アプリケーションがリクエストを送る前にまずドメイン名解決を行う。システムはドメイン名をDNSサーバーに渡し、実際のIPアドレスを取得したうえで、そのIPに接続する。Clashがドメイン名ベースの振り分け(たとえば「特定サイトはプロキシ経由、それ以外は直接接続」)を行うには、この段階で介入する必要がある——問題は、振り分けルールに書かれているのは多くの場合ドメイン名(DOMAIN-SUFFIX、DOMAIN-KEYWORD)であるのに対し、実際のネットワーク接続で使われるのはIPアドレスだという点だ。特別な処理をしなければ、ルールエンジンは接続が発生した時点で裸のIPしか見えず、それがどのドメイン名に対応し、どのルールにマッチすべきかを逆引きすることは必ずしも確実ではない。

これが、Clash Meta(mihomo)がDNSレイヤーで複数のモードを提供している理由であり、最も一般的なのがFake-IPとredir-host(fake-ip以外のリダイレクトモード)の2つだ。両者は本質的には同じ課題——「IPレイヤーでの接続」が発生した際にも「ドメインルール」を正しく対応させる方法——を解決しているが、そのアプローチはまったく異なり、挙動の違いも小さくない。

Fake-IPの動作メカニズム

Fake-IPの発想はこうだ:アプリケーションが何らかのドメイン名のDNSクエリを送ると、Clashは実際にそのドメインを解決するのではなく、予約されたプライベートアドレス帯(デフォルトでは198.18.0.0/16が多い)から未割り当てのアドレスを1つ選び、即座にアプリケーションへ返す。同時に内部で「仮想IP ↔ 実ドメイン名」の対応表を維持する。

1. アプリケーションがexample.comのAレコードを問い合わせる;
2. ClashのDNSモジュールがこのクエリを捕捉し、fake-ip(例:198.18.0.23)を割り当てて「198.18.0.23 は example.com に対応する」と記録する;
3. アプリケーションは198.18.0.23を取得し、TCP/UDP接続を開始する;
4. 接続はClash(システムプロキシポートであれTUN仮想ネットワークカードであれ)を経由し、Clashはテーブルを参照して元のドメイン名example.comを復元する;
5. ルールエンジンは復元されたドメイン名を使ってDOMAIN系ルールとマッチングし、どのプロキシノードを使うかを決定する;
6. ポリシーが確定すると、Clashは実際のドメイン名に対する本当の解決を行う(宛先が直接接続ノードの場合)か、SNIをサポートするプロキシプロトコルにドメイン名をそのまま渡し、実際のアウトバウンド接続を確立する。

この一連の流れの中で、アプリケーションが感知するのは「即答」のDNS応答だ——Fake-IPはそもそもネットワークを経由して権威DNSサーバーに問い合わせておらず、ローカルの予約アドレスを割り当てるだけなのでほぼ遅延はない。これがredir-hostに対する最も直接的な優位性であり、DNSクエリの遅延がほぼゼロになるうえ、ルールマッチング段階で得られるのがIPではなく完全なドメイン名であるため、DOMAINルールのマッチ精度も高くなる。

Fake-IPとredir-hostの違い

redir-hostモードは別の道を行く:Clashは実際にドメイン名を利用可能なIPに解決してアプリケーションへ返すが、プロキシ転送の段階でHTTPのHostヘッダーやTLSのSNIフィールドを読み取ってドメイン名を再識別し、それをルールとマッチさせる。そのメリットはアプリケーションが常に実際のIPを取得できることで、実IPに強く依存する一部のシーン(プログラム自身がIPホワイトリスト判定を行う場合など)では問題が起きにくい。代償として、クエリごとに実際の解決を行う必要があるためDNSの遅延がそのまま残り、平文のドメイン情報を含まないプロトコル(一部のUDPアプリケーションや非標準ポートの通信)に対する識別能力には限界がある。

Clash Meta(mihomo)コアのデフォルト配布版の多くはFake-IPをデフォルトまたは推奨モードとしている。特にTUNモードと併用する場合、TUNはシステムの全ネットワークレイヤーのトラフィックを引き受けるため、Fake-IPのドメイン復元メカニズムはシステムプロキシポートを通るトラフィックだけでなく、より広範囲のアプリケーション接続リクエストを網羅できる。

Fake-IPで注意すべき落とし穴

Fake-IPにも代償がないわけではなく、以下のようなシーンはコミュニティでの報告頻度が高い問題だ:

• LAN内サービスの解決異常:NAS、ルーターの管理画面、LAN内プリンターなどのデバイスのドメイン名までFake-IPに引き受けられてしまうと、アプリケーションが取得するのは仮想アドレスとなり、その接続がClashを経由しない場合(LAN内直接通信でプロキシを経由しないなど)、接続が失敗する。
• 実IPによる検証が必要なプログラム:一部のクライアントソフトはアプリケーション層で解決されたIPを記録・照合する(一部の企業向けVPNクライアントや証明書バインディング検証が厳しいサービスに多い)。Fake-IPが返す仮想アドレスでは、この種の検証が通らなくなる。
• IPベースの地理位置判定の誤り:あるプログラムがDNSから返されたIPを使って独自に地域判定を行っている場合(標準的なドメイン接続フローを使っていない場合)、Fake-IPの予約アドレス帯には当然地理情報がないため、判定結果が不正確になる。
• 一部のmDNS/LAN発見プロトコルとの競合:LANデバイスの発見は実際のネットワーク帯内でのアドレスブロードキャストに依存しており、Fake-IPに引き受けられるとデバイス発見が機能しなくなることがある。

これらのシーンに共通するのは、本来「直接接続で、Clashの振り分けの影響を受けない」はずのドメイン名が、Fake-IPのデフォルトの適用範囲に入ってしまったために問題が起きているという点だ。解決策はFake-IPをオフにすることではなく、こうしたドメイン名を適用範囲から正確に除外することにある——これこそがfake-ip-filterの存在意義だ。

fake-ip-filterの除外リストの書き方

この設定項目はDNS設定ブロックの下にあり、「Fake-IPモードであっても、応答を偽装せず実際の解決を行う」ドメインルールをまとめて宣言する役割を持つ。ワイルドカードに対応しており、基本構造は以下の通り:

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 8.8.8.8
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.market.xiaomi.com"
    - "time.*.com"
    - "ntp.*.com"
    - "*.msftncsi.com"
    - "www.msftconnecttest.com"

よく使う書き方のポイント:

1. *.lanや*.localといったワイルドカード付きサフィックスは、LANデバイスによくあるローカルドメインサフィックスを除外するために使う;
2. ルーターやNASの管理パネルが固定のドメイン名(メーカーが割り当てるDDNSドメインなど)を使っている場合は、個別に1行追加して正確に除外することを推奨する;
3. システムレベルのネット接続検出用ドメイン(Windowsのmsftncsi.com、msftconnecttest.comなど)は実際の解決を保持し、システムが「ネットワーク未接続」と誤判定するのを避ける;
4. 時刻同期(NTP)関連のドメインは除外を推奨する。一部のクライアントは時刻同期の応答遅延に敏感である;
5. 特定のAppのログイン/検証用ドメインで接続異常が繰り返し発生する場合は、まずそれをfilterに単独で追加して試し、問題が解消するかどうかを確認するとよい。

redir-hostへ切り替える、あるいはFake-IPを無効にすべきケース

Fake-IPは大多数の利用シーンにおいて適切なデフォルト選択であり、特にルール振り分けやTUNモードと組み合わせるとより一貫した体験が得られる。ただし以下のような場合は切り替えや調整を検討してもよい:

• ネットワーク環境全体がLAN内の複数デバイス間のドメイン名相互通信に大きく依存している(家庭用NASクラスターや自前のLANサービスが多い)場合、除外リストの維持コストがメリットを上回っている;
• 使用しているクライアントソフトが「取得するDNS結果は必ず実際のパブリックIPでなければならない」と明確に要求し、かつそのソフトがFake-IPのアドレス帯を許容できない;
• 非常に基本的な振り分け機能だけを必要としており、DNS遅延には敏感ではなく、「見たものがそのまま」の実IPで確認できる体験(pingやnslookupなどのツールで直接確認しやすい)を重視する。

切り替え方はシンプルで、enhanced-modeをfake-ipからredir-hostに変更するだけでよく、ルールセット自体を変更する必要はない。DOMAIN系ルールはどちらのモードでも正常に機能し、違いは下層の応答メカニズムだけにある。

トラブルシューティングの手順まとめ

「特定のドメインに接続できないが、直接接続は正常でプロキシルールにも問題が見当たらない」という状況に遭遇した場合、以下の順序で確認するとよい:

1. 現在のDNSモードを確認する(設定ファイルのenhanced-modeフィールド、またはクライアント画面のDNS設定を確認);
2. Fake-IPモードの場合、そのドメインまたは所属するネットワーク帯が本来LAN内直接接続すべきものなのにfake-ip-filterに追加されていないかを確認する;
3. クライアントのログや接続パネルを確認し、この接続の宛先IPがfake-ip-rangeで宣言されたネットワーク帯(デフォルトでは多くが198.18.0.0/16)に含まれているかを確認する;
4. 疑わしいドメインを一時的にfake-ip-filterに追加してコアを再起動し、問題が解消するかテストする;
5. それでも解決しない場合は、enhanced-modeを一時的にredir-hostに切り替えて比較テストを行い、問題の範囲を絞り込む。

Fake-IPの応答メカニズムを理解すれば、「DNS関連の接続異常」の大半は「このドメインをFake-IPに引き受けさせるべきかどうか」という1つの問題に帰結できる。トラブルシューティングの道筋は、最初に想像するよりもずっと明確になるはずだ。