ClashのFake-IPとは？DNSマッピングの仕組みとfake-ip-filterの設定

まず結論：Fake-IPはドメインのマッピング機能であり、プロキシの出口ではない

Fake-IPモードでは、Clashのコアがアプリに合成アドレスを返し、接続を処理する際にそのアドレスをドメインへ復元します。アプリに表示されるアドレスが198.18.0.2でも、実際のWebサイトやプロキシの出口がこのアドレスにあるわけではありません。このアドレスが表示されたからといって、DNSが汚染されているとは限らず、通信がプロキシ経由かどうかも判断できません。

この仕組みを機能させるには、2つの処理が必要です。DNSクエリをコアに処理させ、その後、合成アドレス宛ての接続も同じコアに戻します。デスクトップではTUNで通信を取り込み、ルーターでは透過プロキシのルールで処理するのが一般的です。設定にenhanced-mode: fake-ipと記述するだけで、OSのルーティングやDNS転送がすべて自動設定されるわけではありません。

DNSマッピングから接続時の復元まで：5つの手順

アプリがexample.com:443にアクセスする場合を例に、DNSと接続の両方が同じmihomoインスタンスで処理されると仮定したときの流れを説明します。

1. アプリがDNSクエリを送信。アプリがexample.comのIPv4アドレスを要求し、クエリがコアのDNSサービスに届きます。アプリが別の暗号化DNSを使っていて、通信が取り込まれていない場合、この処理はコアを迂回する可能性があります。
2. コアが合成アドレスを割り当て。ドメインが除外リストに該当しなければ、コアはFake-IPのアドレスプールから198.18.0.2などのアドレスを割り当て、ドメインとの対応を保存します。有効なマッピングがすでにあれば再利用できます。
3. アプリが合成アドレスに接続。通常のネットワーク処理と同じように、アプリが198.18.0.2:443への接続を開始します。TUNまたは透過プロキシのルールによって接続はコアに戻され、インターネットへ直接送信されることはありません。
4. コアが元のドメインを復元。コアがマッピングを参照してexample.comを復元し、そのドメインに基づいてルールを適用し、プロキシグループを選択して接続を処理します。
5. 出口に応じて実際の接続を確立。プロキシ経由の場合、プロトコルと実装がドメイン名の転送に対応していれば、プロキシ側で名前解決できます。直結の場合、通常はローカルのコアで実際の名前解決が必要です。詳細はルールとDNSの設定によって異なります。

198.18.0.0/15はネットワーク機器のベンチマーク用に予約された特殊用途のアドレス範囲で、Webサイトが実際に使うパブリックIPではありません。一般的な設定では、その範囲内の198.18.0.1/16をアドレスプールとして使います。企業ネットワークですでにこの範囲を使用している場合は、ルーティングの競合を先に解消してください。デフォルト値をそのまま適用するのは避けましょう。

ドメイン情報を保持するとルールで振り分けやすくなる

共有CDNのIPアドレスしか分からない場合、コアはそのアドレスだけで異なるWebサイトを見分けるのが困難です。Fake-IPのマッピングでドメイン情報を保持すれば、DOMAINやDOMAIN-SUFFIXなどのルールに照合できます。ただし、ルールは上から順に適用されます。先にあるプロセスルールやIP範囲のルールなどが、出口を先に決める場合もあります。

初回接続の遅延：短縮できる待ち時間

Fake-IPではアプリに早くアドレスを返し、接続処理を先に始められます。実際のAレコードが返るまで待たずに、アプリへ使える合成アドレスを返せるためです。実際の名前解決結果を待つ必要がある経路と比べると、接続開始前の待ち時間が短くなる可能性があります。ただし、すべてのWebサイトで常に速くなるわけではありません。

たとえば、キャッシュされていないDNSクエリに80ミリ秒かかるとします。Fake-IPなら、アプリは接続を開始する前にその80ミリ秒を待つ必要がありません。これは仕組みを説明するための仮定で、実測した効果ではありません。その後の直結時の名前解決、プロキシとのハンドシェイク、TLSハンドシェイク、サーバーからの応答には、引き続き時間がかかります。

意味のある比較方法

• 同じネットワーク、同じノード、同じルールモードで、キャッシュが空の状態と温まった状態をそれぞれテストし、結果を混同しないようにします。
• ブラウザーの開発者ツールにある「ネットワーク」パネルでDNS・接続・TLSの各段階を確認し、コアのログも確認します。ブラウザーに表示されるDNS時間に、コアが後から行う名前解決の時間が含まれているとは限りません。
• 複数回のページ読み込みを記録し、中央値を確認します。DNS応答速度とページのTTFB（最初の1バイトを受信するまでの時間）を分けて評価してください。ダウンロード速度の測定を1回行っただけで、DNSの比較結果としないようにしましょう。

最小限のDNS設定と検証コマンド

以下は設定例であり、インターネットに接続できる完全な設定ではありません。コアのDNSを有効にし、ローカルの1053番ポートで待ち受けるだけです。プロキシノード、ルール、TUN、システムDNSの取り込みは、既存の設定で用意する必要があります。ここでは検証対象をIPv4のAレコードに限定するためIPv6を無効にしています。通常利用では、ネットワークがIPv6の通信取り込みに対応しているかを確認して有効・無効を決めてください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

この2つの上流DNSアドレスに、現在のネットワークから到達できる必要があります。社内・学校・家庭でDNSを使い分けている場合は、適切な内部リゾルバーを指定してください。すべてのクエリをパブリックDNSへ送ると、内部ドメインを解決できない場合があります。127.0.0.1での待ち受けはローカルマシンからのクエリのみを受け付けるため、ほかのLAN機器が直接利用するDNSサーバーには適しません。

まずコアをテストし、次にシステムの名前解決経路を確認

コアを起動したデバイスで、サーバーとポートを明示して次のコマンドを実行します。Windowsでは1つ目を、digをインストールしたmacOSまたはLinuxでは2つ目を使えます。2つは代替コマンドなので、両方を続けて実行する必要はありません。

nslookup -port=1053 example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A +short

1. 返されたアドレスが、設定したFake-IPのアドレスプール内にあることを確認します。タイムアウトする場合は、まずコアが起動しているか、ポートが使用中でないか、適用後の設定でDNSが有効かを確認してください。
2. 次に、システムのデフォルト設定で同じドメインを名前解決します。ポートを指定したクエリは成功するのにシステムの結果が異なる場合、アプリまたはシステムのDNSクエリがこの経路を通っていません。
3. クライアントの「接続」画面で、ブラウザーから直前に送信したリクエストを探し、宛先ドメイン、適用ルール、出口のプロキシグループを確認します。DNSが合成アドレスを返したことだけでは、名前解決の処理しか確認できず、接続が取り込まれた証拠にはなりません。

fake-ip-filter：実アドレスを返すドメインの設定

fake-ip-filterは、どのDNSクエリに合成アドレスを割り当てないかを指定します。一般的なデフォルトのブラックリスト方式では、リストに一致するドメインに実際の名前解決結果を返します。新しいmihomoにはフィルターモードなどの拡張設定もあります。既存の設定にfake-ip-filter-modeが含まれている場合は、リストの意味を除外対象と決めつけず、まずモードの仕様を確認してください。

フィルターリストは、直結かプロキシ経由かを決めるものでも、内部DNSを選択するものでもありません。リストに追加したドメインもルールに従ってプロキシ経由にできます。また、ルールでDIRECTに指定したドメインが、自動的にFake-IPを回避するわけではありません。

LAN内ドメインには適切な上流DNSも必要

+.home.arpaはそのドメインとサブドメインを表し、この命名規則を採用している家庭内ネットワークに適しています。.lanはローカルネットワークでよく使われる慣習ですが、すべてのルーターが採用しているわけではありません。.localは通常mDNSに関係します。これをフィルターリストに追加しても、通常のDNS上流にmDNSの探索機能が備わるわけではありません。プリンターが見つからない場合は、マルチキャストとローカルネットワークへのアクセス許可も確認してください。

ゲームやアドレス検証のドメインは、根拠を確認して追加

ゲームプラットフォーム全体やCDNのドメインをまとめて除外しないでください。まず問題が起きた時刻を記録し、接続ログとDNSログから該当リクエストを特定して、問題のあるドメインだけを追加します。以下のlogin.example.comは書式を示す例です。実際にゲームの問題を解決するときは、そのまま使わず、ログで確認した宛先に置き換えてください。

dns:
  fake-ip-filter:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
    - "login.example.com"

以下の項目は既存のdnsオブジェクトに統合してください。同じYAMLファイルにトップレベルのdnsキーを2つ作成しないようにします。サブスクリプションがサーバー側から定期更新される場合は、クライアントのオーバーライド機能またはマージ機能で変更を保存し、更新後に実際に適用された設定を確認してください。

よくあるトラブル：名前解決はできるのに接続できない

198.18のアドレスが返るのにWebページがタイムアウトする

まず、接続がコアに戻っているか確認してください。システムプロキシが対象にできるのは、通常、プロキシ設定に従うアプリに限られます。合成アドレス宛てのすべての接続を自動的に取り込むわけではありません。TUNを使う場合は、TUNが起動しているか、ルートが正しく設定されているか、別のVPNがルートを奪っていないかを確認します。テスト中は通信を取り込むネットワークツールを1つだけ使い、DNSと通信が別々のインスタンスに分かれないようにしてください。

クライアントを終了しても一部のWebサイトにアクセスできない

アプリやOSに合成アドレスがキャッシュされたまま、マッピングを復元するコアが終了している可能性があります。まずシステムDNSとルートを元に戻し、関連アプリを終了してDNSキャッシュを削除してください。Windowsではipconfig /flushdns、systemd-resolvedを使うLinuxではresolvectl flush-cachesを実行します。ブラウザー独自のキャッシュもあるため、システムのキャッシュを削除しても直らない場合はブラウザーを再起動してください。

フィルターリストに追加しても変化がない

1. 変更した設定が現在使われているものか、別の設定やグローバルオーバーライドで上書きされていないかを確認してください。
2. フィルターモードとドメインの書式を確認し、Webページのアドレスバーに表示されたメインドメインではなく、実際に問い合わせられたドメインを追加したか確認してください。
3. 設定を適用したら、アプリとシステムに残っている古いDNSキャッシュを削除し、再度名前解決してテストしてください。
4. 実アドレスが返っているのに接続できない場合は、ルール、UDP対応、サーバーの状態、内部DNSを確認してください。フィルターの範囲をさらに広げないようにしましょう。

ブラウザーは使えるのにゲームやコマンドラインのアプリで問題が起きる

ブラウザーとアプリでDNSの経路が異なる場合や、一方はシステムプロキシを使い、もう一方は直接通信している場合があります。アプリ内蔵のDoH、固定IPアドレス、LAN内のマルチキャストは、同じ処理経路を通るとは限りません。ドメインスニッフィングで一部の接続情報を補えることはありますが、すべてのプロトコルでドメインを復元できるわけではなく、DNSやルーティングを確実に取り込む代わりにもなりません。

IPアドレスを直接使う接続には、そもそも「ドメインを問い合わせて偽のアドレスを割り当てる」処理がありません。この場合はIPルール、プロセスルール、接続ログを確認してください。fake-ip-filterに項目を追加しても解決しません。

利用に適した場面と変更前のチェックリスト

日常的なWeb閲覧、ドメイン単位での細かな振り分け、TUNを安定して使えるデバイスでは、まずFake-IPを試すのがよいでしょう。内部DNS、特殊な探索プロトコル、アドレスの整合性チェックに依存する環境では、実際の名前解決、内部DNSの上流、ルーティング設計をまとめて確認する必要があります。

• まずコアを確認。クライアントとコアのバージョンを記録し、現在のコアが設定項目に対応していることを確認します。
• 次に2つの経路を確認。DNSクエリがコアに届き、合成アドレス宛ての接続も同じインスタンスに戻ることを確認します。
• フィルターは必要最小限に。実アドレスが必要だと確認できたドメインだけを追加し、その理由も記録します。
• サブスクリプションの上書きを確認。更新後に最終的な設定を確認し、手動での修正が上書きされていないか確かめます。
• 一度に変更する設定は1種類だけ。まずフィルターだけを変更して様子を見ます。DNS、ノード、ルール、TUNの設定を同時に変更しないでください。