DNS 解決はプロキシ経路のどこで詰まるのか
Fake-IP の役割を理解するには、まずこれがない場合にプロキシソフトが踏む一連の流れを見る必要があります。クライアントがドメインにアクセスすると、システムはまず DNS クエリを発行し、実際の IP を取得してから TCP 接続を確立します。この接続がプロキシを経由する必要がある場合、コアはルール(ドメインサフィックス、IPレンジ、GEOIP など)に基づいてどのプロキシグループで転送するかを決定します。問題は、ルール照合には多くの場合ドメイン情報が必要であり、IP を取得してから判断するのでは間に合わないという点です。DNS クエリ自体もプロキシを経由したり乗っ取られたりする場合、初回パケットが確立される前に一往復、あるいは二往復分のネットワーク遅延が余分に発生します。特に TUN モードで全体のトラフィックを引き受けている場合、この遅延は新規接続のたびに積み重なります。
もう一つの矛盾点は、多くの振り分けルールがドメインルール(例:DOMAIN-SUFFIX)で書かれている一方、OS の下層で転送されるのは IP 層のパケットだという点です。TUN モードがネットワークカード層でトラフィックを捕捉する際、得られるのはすでに宛先 IP であり、それがキャリアの DNS やプロキシノード自身が解決した実アドレスである場合、コアは「この接続が元々どのドメインに対応していたか」という情報を失い、ルールエンジンもドメインベースでの判断ができなくなります。
Fake-IP のマッピング機構:仮想アドレスによる位置確保
Fake-IP の発想は、この二つの問題を一挙に解決することです。クライアントが DNS クエリを発行すると、mihomo コアは実際の解決を行わず、予約されたプライベートアドレス帯(一般的な設定では 198.18.0.0/16)から未使用のアドレスを順に取り出してそのままクライアントに返し、同時にメモリ内に「仮想IP ↔ ドメイン」のマッピングテーブルを構築します。クライアントはこの仮アドレスを受け取るとすぐに接続を開始し、TUN ネットワークカードがこの宛先 IP を捕捉すると、コアはマッピングテーブルを参照して実際のドメインを把握します。ルールエンジンは通常通りドメインで照合してどのプロキシノードを使うかを決定し、実際のドメイン解決は接続確立と同じタイミングでプロキシノードまたはコアによって非同期に完了するため、単独で一往復分の時間を占有することはなくなります。
この一連の処理はクライアントにとって透過的です──アプリケーションは自分が受け取ったのが仮アドレスだと知らず、ただそのIPにパケットを送るだけです。これが Fake-IP が初回パケットの時間を大幅に短縮できる理由でもあります。DNS クエリの段階がほぼローカルなテーブル参照になり、ネットワーク遅延に依存しなくなるのです。
マッピングテーブルのライフサイクル
- マッピング関係はメモリ内に保持され、通常は一定の TTL があり、一定時間使用されなかったエントリは回収され新しいドメインに再利用されます。
- 同じドメインへの短時間内の複数回のクエリは同じ仮想 IP を再利用し、同一セッション内でアドレスの安定性を保ちます。
- 仮想アドレス帯の容量には限りがあるため、長時間稼働してアクセスするドメインが極めて多い環境では、たまにアドレスの再利用による一時的なマッピングの混乱が発生することがあり、クライアントの再起動や DNS キャッシュのクリアで解消できます。
Fake-IP と Redir-Host の動作の違い
Redir-Host はもう一つの、比較的古くから使われている DNS 処理方式です。クライアントの DNS クエリはそのまま実際の上流サーバーへ転送され、実IPを取得した上でクライアントに返され、コアはこの実IPをリダイレクトし、「実IP ↔ ドメイン」の逆引きテーブルを維持することでドメイン情報を復元してルール照合に使います。利点はクライアントが常に実アドレスを持つため互換性の問題が少ないことですが、欠点は DNS クエリの段階が短縮されないため本来必要な解決遅延がそのまま残ること、また逆引きテーブルは実IPが重複せず変動しないことに依存しているため、ドメインの背後が CDN で頻繁に IP が変わる場合、逆引き関係が期限切れになりやすいことです。
| 比較項目 | Fake-IP | Redir-Host |
|---|---|---|
| クライアントが受け取るアドレス | 仮想アドレス帯内の仮アドレス | 実際に解決されたアドレス |
| DNS クエリの所要時間 | ローカル参照に近く、ほぼ遅延なし | 実際の上流サーバーの解決を待つ |
| ドメイン照合の根拠 | コアが保持する仮想IPマッピングテーブル | 実IPの逆引きテーブル |
| CDN のIP変更への影響 | 影響を受けにくく、常にドメインで照合 | 影響を受けやすく、逆引きテーブルが遅れる場合がある |
| 互換性リスク | 一部のアプリは特殊なアドレス帯に敏感 | 互換性は比較的良好 |
簡単に言えば、Fake-IP は「ドメイン照合+仮アドレスによる位置確保」によって速度と CDN 環境での安定性を得ていますが、その代償としてクライアントが手にするアドレスは実物ではなく、IP の正当性を積極的に検証する、あるいは証明書ピンニング(certificate pinning)以外のアドレス検証を行う一部のアプリケーションで異常が起きる可能性があります。
Fake-IP を回避またはホワイトリスト化すべき場面
Fake-IP は大多数のウェブブラウジング、動画視聴、ダウンロードといった場面には影響しませんが、以下のようなケースには注意が必要です。通常は fake-ip-filter 設定項目で該当ドメインを Fake-IP の処理対象から除外し、実際の DNS 解決を行わせます。
LAN内デバイスと社内サービス
ルーターの管理画面、NAS、プリンター、社内システムなど、本来LAN内アドレスに解決されるドメインにアクセスする際、Fake-IP に処理されるとクライアントは仮アドレスを受け取り、コアがその後に直接接続かプロキシ経由かを判断することになります。この過程のどこかで処理が適切でないと接続できなくなる可能性があります。多くのディストリビューションではデフォルトで一般的なLANドメインサフィックス(例:.lan、.local)と内部IPレンジをフィルターリストに含めていますが、自前で構築した社内ドメインは手動で追加することを推奨します。
オンラインゲームとP2P系アプリ
一部のオンラインゲーム、P2Pダウンロードツール、LAN内発見プロトコルは、対等接続のネゴシエーションに実IPを利用したり、DNSの返り値が正当かどうかを検証したりします。198.18.0.0/16 のような予約アドレス帯のアドレスを受け取ると、接続を拒否したり照合に失敗したりします。こうしたアプリのドメインは fake-ip-filter のホワイトリストに追加するか、あるいはそのアプリ自体を直接接続に設定し、TUN ネットワークカードでの処理を経由させないほうが確実です。
システムレベルの検出とキャリア連携サービス
一部の通信事業者のブロードバンド認証や、IoTデバイスのクラウド側ペアリング処理では、解決されたIPが特定のアドレス帯に収まっているかを検証するものがあり、仮アドレスを受け取ると異常と判定されます。「インターネットには接続できるが機能が正常に動かない」といった現象が出た場合は、まず Fake-IP の影響かどうかを確認し、その上でホワイトリスト登録するかどうかを判断してください。
設定例とトラブルシューティングの流れ
mihomo コアを例にすると、DNS セクションの一般的な設定構造は以下のとおりで、特に enhanced-mode と fake-ip-filter の2項目に注目してください。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.0/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.stun.*.*"
- "+.stun.*.*.*"
- "time.*.com"
- "*.market.xiaomi.com"
nameserver:
- 223.5.5.5
- 8.8.8.8
「Fake-IP が原因と思われる異常」を調査する際は、次の順序で検証することをおすすめします。
- まず、現象が TUN モードやルールモードを有効にしたときにのみ発生し、直接接続モードでは正常かどうかを確認する。これで DNS 処理方式との関連をほぼ特定できる。
- コアのログやクライアントの接続詳細パネルを確認し、宛先アドレスが 198.18.0.0/16 のような予約アドレス帯に入っているかを見て、Fake-IP 経由であることを確認する。
- 該当するドメインまたはワイルドカードパターンを fake-ip-filter に追加し、コアを再起動または設定を再適用してから再検証する。
- ドメインが固定でない場合(キャリアの検出サービスが頻繁に変わる場合など)は、そのアプリ全体、あるいはそのアプリが属するLANセグメントごと直接接続に設定することも検討する。フィルタールールを一つずつ追加するより効率的な場合がある。
Fake-IP を優先すべきケース
日常的な利用においては、Fake-IP はデフォルトのまま維持すべきです。理由は、大多数のトラフィックに対して接続確立の所要時間を明確に短縮できるためで、特にノードの切り替えが頻繁でアクセスするドメインの種類が多様な使い方ではその差がより顕著になります。特定かつ再現可能な接続異常に遭遇し、それが確かに予約アドレス帯のアドレスによるものだと特定できた場合にのみ、その一部のドメインだけを個別に処理すべきであり、Fake-IP全体を無効にして実解決に戻すのは得策ではありません。そうすると、すべての接続が再び完全な DNS 往復の遅延を負うことになってしまいます。マッピング機構を理解した上で取捨選択することで、速度の利点を保ちつつ、アドレスの正当性に敏感な一部のサービスへの影響も避けられます。