1. Fake-IPが変えるのはDNSの応答。接続先ノードではない

ClashまたはClash Meta（現名称：mihomo）の設定では、dns.enhanced-modeによって内蔵DNSの応答方式を指定します。主な設定値はfake-ipとredir-hostです。サブスクリプションの選択やノードのプロトコルには影響せず、ルールモードやTUNモードの代わりにもなりません。

Fake-IPでは、ドメインに合成アドレスを割り当て、「ドメイン ↔ 合成アドレス」の対応関係を保存します。アプリがそのアドレスに接続すると、コアがドメインを特定し、ルール判定と送信先の処理を行います。このアドレスはWebサーバーの実IPでも、プロキシノードのIPでもありません。

よく使われるアドレスが198.18で始まるのはなぜ？

一般的な設定では、198.18.0.1/16をFake-IPのアドレスプールとして使います。このアドレスはネットワーク機器のベンチマーク用に予約された198.18.0.0/15の範囲内にあり、通常のWebサイトへ直接接続するためのものではありません。設定の/16は、その予約範囲の一部をアドレスプールとして使うことを示します。予約範囲全体がこの範囲だけという意味ではありません。

そのため、DNSの応答に198.18.x.xが含まれていても、それだけでDNSが改ざんされたとは限りません。重要なのは、その後の接続が対応関係を保持している同じコアに戻ることです。アプリが合成アドレスを取得しても、TUNなどの透過的な通信経路を通らずに直接接続すると、通常はアクセスに失敗します。

2. ドメイン問い合わせから接続まで：2つのモードの違い

Fake-IPの一般的な処理の流れ

  1. アプリがexample.comなどのドメインを問い合わせると、コアのDNSに問い合わせが届きます。
  2. コアは合成IPv4アドレスを割り当てるか、既存の割り当てを再利用して、アプリに応答します。
  3. アプリがそのアドレスに接続すると、通信はTUNなどの経路を通じてコアに渡されます。
  4. コアは対応関係からドメインを特定し、ルールを順に確認して、直接接続かプロキシかを選びます。
  5. 実IPが必要な場合は、その時点で名前解決します。プロキシプロトコルと送信設定がドメイン名の転送に対応していれば、接続先のサーバー側で名前解決することもできます。

この仕組みでは、アプリが接続を始める前に実DNSの応答を待つ時間を減らし、コアが元のドメインを取得しやすくなります。ただし、「接続中はDNS問い合わせが一切発生しない」という意味ではありません。直接接続、IPアドレスを使うルール、一部の送信プロトコルや特定の名前解決設定では、実際のDNS問い合わせが必要になる場合があります。

Redir-Hostの一般的な処理の流れ

Redir-Hostでは通常、まず上流DNSサーバーに問い合わせて実アドレスを取得し、そのアドレスをアプリに返します。コアはDNSキャッシュ内の対応情報を使い、接続を受け取った際にドメインを特定できます。DNS問い合わせがコアを経由していない場合や、キャッシュが消えている場合、複数のドメインが同じアドレスを共有している場合は、ドメインを正確に特定できないことがあります。通信のスニッフィングで補えるプロトコルもありますが、すべての接続に有効なわけではありません。

比較項目 Fake-IP Redir-Host
アプリが受け取るIPv4アドレス 通常はアドレスプール内の合成アドレス 通常は上流DNSから返される実アドレス
応答前に実DNSの結果を待つか 通常の合成応答では待つ必要なし キャッシュにない場合は通常、応答を待つ
ドメインルールの判定に必要な情報 主に合成アドレスとの対応情報から取得 DNSの対応情報、明示的なプロキシ情報、スニッフィングなどに依存
互換性で注意したい点 アドレスの検証、LAN内の機器検出、透過的な経路を通らない接続 実DNSの応答遅延、名前解決の結果と接続先の整合性

HTTP CONNECTやSOCKSのドメイン名指定を使う明示的なプロキシ接続では、コアが接続先のドメインを直接取得できる場合があり、ここで説明したOSのDNS問い合わせを経由しないことがあります。そのため、ブラウザーにプロキシを設定してWebサイトにアクセスできても、それだけではFake-IPによるDNSの処理が正常だとは判断できません。

3. 用途に合わせて選ぶ。Fake-IPは速度切り替えスイッチではない

Fake-IPは初回接続時の名前解決待ちを短縮する場合がありますが、サブスクリプションの帯域を増やしたり、ノードの倍率を下げたり、混雑した回線を改善したりするものではありません。ダウンロード速度が遅い場合は、DNSの応答時間、接続確立までの時間、転送中の速度を個別に確認し、別々の問題として切り分けましょう。

4. fake-ip-filter：必要なドメインだけ実アドレスを返す

デフォルトのブラックリスト方式では、fake-ip-filterに指定したドメインには合成アドレスを使わず、通常の名前解決を行います。これはプロキシをバイパスするリストではありません。フィルターに追加したドメインへの接続もrulesに従って判定されます。直接接続が必要な場合は、該当ルールの送信先がDIRECTになっていることも確認してください。

以下はmihomo向けの部分的な設定例です。127.0.0.1:1053は手動確認に使いやすいローカルの待ち受けアドレスですが、これだけでシステムDNSになるわけではありません。既存の設定に統合する際は、トップレベルのdns:を1つだけ残し、必要なDNSの振り分け、上流サーバーのアドレス、その他の項目も維持してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - localhost
    - "+.lan"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

上流DNSのアドレスは設定例の構造を示すためのものです。実際には、現在のネットワークから接続でき、LAN内の要件に合ったDNSサーバーを選んでください。mihomoのドメイン照合構文では、+.home.arpaはそのドメイン自体とサブドメインに一致します。旧バージョンのClashコアを使う場合は、対応する項目と照合構文を事前に確認してください。旧コアがfake-ip-filter-modeに対応しているとは限りません。

1つずつ確認したい除外対象

.localは通常mDNSに使われ、一般的なユニキャストDNSとは異なります。該当する名前をフィルターに追加しても、TUNがマルチキャストによる機器検出の通信を自動転送するわけではありません。画面共有やプリンターが見つからない場合は、LANへのアクセス権、マルチキャストの経路、ファイアウォールも確認してください。

5. LAN内の名前解決とルールによる振り分けは別々に設定

「実アドレスを返すか」「どのDNSサーバーに問い合わせるか」「接続をどの経路に送るか」は、それぞれ別の設定です。たとえばNASのドメインがnas.home.arpaで、ルーターのアドレスが192.168.1.1なら、上の例にDNSの振り分け設定を追加し、先に一致する可能性のある広範囲のルールより前に直接接続のルールを置けます。

# 以下の項目を既存の dns に統合してください。dns をもう1つ作成しないでください。
dns:
  nameserver-policy:
    "+.home.arpa": "192.168.1.1"

# 以下のルールを既存の rules に追加し、照合順序に注意してください。
rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT

これは既存設定への追加位置を示す例であり、サブスクリプションをそのまま置き換える完全な設定ではありません。例の192.168.1.1は実際のLAN内DNSサーバーのアドレスに置き換えてください。現在のネットワークから接続できない場合、フィルターが正しくても有効な応答は得られません。

サブスクリプションの更新で手動変更が上書きされる場合があります。クライアントのオーバーライド、拡張設定、マージ機能を使う際は、最終的に生成された実行設定を確認してください。フィルター項目が維持されているか、DNSの振り分け設定が統合されているか、直接接続のルールがフォールバックルールより前にあるかを確認します。画面に「保存しました」と表示されても、コアが新しい設定を読み込んだとは限りません。

6. DNS問い合わせと接続ログで設定を確認

手順1：実行中のコア設定を確認する

クライアントに表示されているコアの名称とバージョンを記録し、実行設定のenhanced-mode、listen、フィルターリスト、TUNのDNS横取り設定を確認します。クライアントの画面上で設定項目が再生成されることがあるため、読み込み後の設定とログを基準にしてください。コアが未対応の項目を報告した場合は、互換性の問題を先に解消してからテストしましょう。

手順2：ローカルのDNS待ち受けポートへ直接問い合わせる

実際の待ち受け設定が上の例と同じ場合は、digをインストールした環境で次のコマンドを実行します。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 nas.home.arpa A

Windowsでは、nslookupの対話モードでポートを指定できます。

nslookup
> server 127.0.0.1
> set port=1053
> set type=A
> example.com
> nas.home.arpa
> exit

1つ目のドメインがフィルター対象でなければ、通常はアドレスプール内のIPv4アドレスが返ります。2つ目のドメインは、LAN内DNSにそのレコードが設定されている場合に限り、対応するLAN内アドレスが返ります。正解として特定の198.18.x.xを決めつけないでください。割り当てられるアドレスは対応関係の状態によって変わります。

手順3：システムが使うDNSと接続経路を確認する

  1. アプリの既存の接続を終了してからアクセスし直し、クライアントの「接続」画面で対象ドメイン、適用されたルール、送信先のポリシーを確認します。
  2. 手動でのDNS問い合わせは成功するのにアプリからアクセスできない場合は、システムDNSがコアを経由しているか、TUNが合成アドレスへの接続を処理しているかを確認してください。
  3. アプリ独自の暗号化DNSを使っている場合は、まず設定を記録し、比較のため一時的に無効にします。アプリ内のDoH問い合わせは、コアの通常のDNS待ち受けを経由しないことがあります。
  4. IPv6の通信だけに問題がある場合は、AAAA問い合わせ、IPv6ルート、通信の横取り設定を個別に確認してください。Aレコードのテストが成功しても、IPv6が正常とは限りません。

モードを切り替えた後、Windowsではipconfig /flushdnsを実行してシステムのDNSキャッシュを消去し、テストするアプリを再起動できます。ブラウザー、アプリ、コアがそれぞれキャッシュや長時間接続を保持する場合もあるため、ページを再読み込みするだけでは新しいDNS問い合わせが発生しないことがあります。

7. よくあるトラブル：どの処理段階で失敗しているか確認

クライアント終了後も、サイトが198.18のアドレスへ接続しようとする

DNSキャッシュの残留、古い接続、システムのネットワーク設定が元に戻っていない状態を確認してください。通常のDNS設定とプロキシ設定に戻し、システムのキャッシュを消去してから、アプリを終了して再起動します。合成アドレスにパブリックゲートウェイを設定しないでください。対応関係と通信の横取りがなければ、直接接続できるWebサイトのアドレスではありません。

フィルターを追加しても、イントラネットのサイトにアクセスできない

まず、フィルターを適用した後に実際のDNS応答を確認します。応答がない、またはタイムアウトする場合は、名前解決の経路に問題があります。正しいLAN内IPが返っている場合は、接続ルール、ルーティング、ファイアウォールを確認してください。フィルターが行うのは「合成アドレスを返さない」ことだけです。LAN内DNSを自動検出したり、LANへの接続を自動で許可したりはしません。

Webサイトは表示できるのに、合成アドレスへのpingが失敗する

pingはICMPを使うため、Webページで使われるTCPやQUICの通信とは異なります。ICMPの処理方法はコアや通信の横取り方式によって異なり、合成アドレスへのping結果はノードの遅延を示すものでもありません。実際のアプリからのアクセス、接続ログ、対象サービスに合わせたテストを基準にしてください。

Redir-Hostに切り替えて直った場合、ずっと使い続けるべき？

まずは正常に動作する設定を維持し、差が生じた原因を特定してください。影響があるのが1つのサービスだけなら、該当ドメインだけをフィルターに追加し、LAN内の名前解決が正しいかを確認します。多くのアプリが実DNSアドレスを必要とする場合は、Redir-Hostを継続利用する選択肢もあります。判断基準は、接続を再現できること、意図したルールが適用されること、運用の手間を抑えられることであり、どちらのモード名が先進的かではありません。