Fake-IPモードの仕組み：DNSマッピングでスマホの初回接続待ちを短縮

まず確認：DNS応答と接続完了は別

スマートフォンでWebサイトを開くと、アプリは通常、まずドメインに対応するIPアドレスを調べてから接続します。Clash Meta（mihomo）のDNS機能に対応したクライアントでenhanced-mode: fake-ipを使うと、DNS応答の方法が変わります。カーネルがドメインごとに一時的な合成アドレスを割り当て、「ドメイン ↔ 合成アドレス」の対応をマッピングテーブルに記録してから、そのアドレスをアプリに返します。

その後、アプリはこのアドレスに接続します。クライアントが通信を受け取ると、カーネルはマッピングテーブルから元のドメインを特定し、ドメインに一致するルールに基づいて、直接接続するかプロキシ経由にするかを選びます。合成アドレスはクライアント内部で使うインデックスであり、Webサイトの実際のサーバーアドレスではありません。インターネットからアクセスできる宛先として扱うべきものでもありません。

リクエスト処理の流れ

1. アプリがexample.comのAレコードを問い合わせます。この問い合わせはクライアントのDNS処理を経由する必要があります。
2. カーネルは設定済みのFake-IPアドレス範囲から1つを返し、example.comとの対応を保存します。
3. アプリがそのアドレスに接続すると、クライアントが通信を受け取り、ドメインを特定してDOMAINやDOMAIN-SUFFIXなどのルールを適用します。
4. カーネルは選択された出力方式で宛先への接続を処理します。プロキシ経由でドメインを使って接続できるかどうかは、プロトコル、ノード、クライアントの実装によって異なります。

つまり、「DNS応答を受け取ること」と「宛先に接続できること」は別です。Fake-IPは、アプリが後続のルール判定に使えるアドレスを早く受け取れるようにしますが、実際の通信にはルール判定、ノードへの接続、接続先サービスからの応答が必要です。アプリがIPアドレスを直接指定する場合や、DNS問い合わせがクライアントを経由しない場合、後続の接続がクライアントに捕捉されない場合は、このドメインマッピングの仕組みは通常どおり機能しません。

Fake-IPとredir-host：実際の名前解決を行うタイミング

redir-hostは通常、アプリにDNS応答を返す前に上流DNSで実際のIPアドレスを取得し、その結果をアプリに返します。一方、fake-ipは先に合成アドレスを返し、後からクライアントが通信を捕捉した際にマッピングテーブルからドメインを復元します。大きな違いは「DNSを使うかどうか」ではなく、アプリがDNS応答を待つ間に、通常は対象ドメインの実際の名前解決を待つ必要があるかどうかです。

「初回接続待ちの短縮」とは、主にDNS処理中に実際の名前解決を待つ時間を減らせる可能性を指します。Webサイトへのリクエストが毎回速くなるという意味ではありません。遅延の原因がノードとのハンドシェイク、パケットロス、接続先の応答、アプリの起動処理にある場合、DNSモードを切り替えても初回応答までの時間は改善しないことがあります。直接接続でも最終的には実際の名前解決が必要になる場合があります。その時間は後続の処理に移るだけで、全体の所要時間から消えるわけではありません。

モードを比較するときは、同じネットワーク、同じノード、同じ接続先を使いましょう。まずアプリが安定して接続できるかを確認し、そのうえで待ち時間を比較してください。DNS応答が速いからといって、ページの読み込み全体も速いとは限りません。

予約アドレス範囲とマッピングテーブルの連携

mihomoの設定でよく見られるfake-ip-rangeの例は198.18.0.1/16です。198.18.0.0/15はネットワーク機器のベンチマーク用に予約されたIPv4アドレス空間であり、一般的なインターネット上のWebサイトで使われるアドレスではありません。この範囲の一部をローカルの合成アドレスに使うことで、カーネルが該当する通信を識別しやすくなります。実際に使うアドレス範囲は、現在のクライアント設定を確認してください。

マッピングテーブルは稼働中のカーネルが管理するもので、永続的に使えるWebサイトのIPアドレス一覧ではありません。同じ合成アドレスが、異なる稼働時点でも常に同じドメインに対応するとは限りません。合成アドレスを別の端末にコピーしたり、アプリの設定に長期間登録したり、クライアントの再起動後にそのアドレスだけで接続テストをしたりしても、元のドメインの状態を正しく確認することはできません。

最小限のDNS設定例

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - '*.lan'
    - printer.home.arpa

このYAMLは設定項目の位置を示す例であり、あらゆるネットワークで使える完全な設定ではありません。nameserverのアドレスは説明用です。利用するネットワークやサブスクリプション設定、実際の接続可否に合わせてDNSサーバーを選んでください。fake-ip-filterには合成アドレスを返さないドメインを指定します。具体的なマッチング構文や、クライアント上でこれらの項目を編集できるかどうかは、使用するカーネルとクライアントのバージョンによって異なります。編集時はインデントを半角スペース2つにそろえ、元の設定を先にバックアップしてください。

enhanced-modeをfake-ipに変更するだけでは、動作するとは限りません。アプリのDNS問い合わせがクライアントを経由し、合成アドレス宛ての後続通信もクライアントに捕捉される必要があります。スマートフォンでは通常、システムVPNの設定、クライアントのDNS設定、選択中のプロキシモードも関係します。クライアントによってはこれらの項目をGUIで管理しており、ユーザーが編集したYAMLを直接読み込まない場合があります。

フィルターに追加するとよい接続先

判断の基準は、対象のアプリが実際のアドレスを必要とするか、通信が常に同じクライアントカーネルを経由するかどうかです。すべてのドメインをまとめてフィルターに追加するのは避けましょう。フィルターの範囲を広げるほど、実際の名前解決を待つ問い合わせが増え、減らしたかったDNS待ち時間が再び発生する可能性があります。

LAN機器：まず名前解決の経路を確認

プリンター、NAS、ルーターでは、printer.lanやnas.home.arpaのようなLAN内の名前がよく使われます。機器管理アプリがLAN内の実際のアドレスを必要としているのに合成アドレスが返される場合は、まずその機器の正確なドメイン名をフィルターに追加し、現在のDNS上流がLAN内の名前を解決できるか確認してください。フィルターで変わるのはFake-IPを返すかどうかだけです。パブリックDNSがプリンターのアドレスを知らなければ、フィルターを追加しても名前解決はできません。

.localの名前は、通常のDNS問い合わせではなく、mDNSでLAN内の機器を検出することがよくあります。「機器一覧には表示されるのに、選択すると接続できない」場合は、LANへのアクセス許可、mDNSによる検出、実際の接続で使われるドメイン名またはIPアドレス、プロキシルールをそれぞれ確認してください。アプリが192.168.1.1へ直接アクセスする場合、Fake-IPフィルターはIPアドレスを直接使うこの接続には影響しません。

ゲームや一部のアプリ：ドメインごとに確認

ゲームのログイン、マッチング、ボイスチャットでは、異なるドメインやUDP接続が使われる場合があります。まず、アカウントへのログイン、ルームのマッチング、リアルタイム通信のどこで止まるのかを切り分けましょう。Fake-IPで特定のドメインだけに問題が起き、実際の名前解決に切り替えると解消する場合は、そのドメインだけをフィルターに追加します。アプリによっては名前解決の結果をキャッシュします。設定変更後はアプリを終了して再起動し、必要に応じてクライアントも再接続して、古い接続やキャッシュがテストに影響しないようにしてください。

「ゲームはUDPを使うからFake-IPを無効にする必要がある」とは限りません。UDP通信が正常に動作するかどうかは、クライアントの通信捕捉方式、ノードのプロトコル、ルール、サーバー側の状況にも左右されます。IPアドレスの直接指定、LAN内ブロードキャスト、機器検出を使う機能では、ドメインフィルターが関係しないこともあります。その場合、ドメインを追加し続けても設定が複雑になるだけです。

iPhoneでの確認手順

DNSモードの切り替え後に、接続できない、一部のアプリが読み込み中のままになる、LAN機器がオフラインになるといった問題が起きた場合は、「システムによる通信捕捉 → DNS応答 → 接続ルール → 個別アプリ」の順に確認しましょう。ノード、サブスクリプション、DNS上流を同時に変更するより、原因を特定しやすくなります。

1. VPNが接続済みか確認します。iPhoneの「設定」→「一般」→「VPNとデバイス管理」→「VPN」で接続状態を確認し、クライアントに戻って想定した設定が有効になっているかを確認してください。システムメニューの名称はiOSのバージョンによって異なる場合があります。
2. 設定が有効になっているか確認します。現在のProfileで、DNSモード、Fake-IPアドレス範囲、ルールモードを確認してください。サブスクリプションの更新後に別のProfileへ切り替わっている場合は、実際に有効な設定の項目を確認します。
3. すべての通信の異常か、特定の通信だけの異常かを切り分けます。どのWebサイトにもアクセスできない場合は、DNS上流への接続、VPNによる通信捕捉、ノードを優先して確認します。NAS 1台や特定のアプリだけに問題がある場合は、アクセス先のドメイン名またはLAN内アドレスを記録してください。
4. 変更は一度に1か所だけにします。対象が明確なLAN内ドメインをフィルターに追加して再接続し、接続先を再テストします。変化がなければ変更を元に戻し、LAN内の名前解決、直接接続ルール、アプリのアクセス許可を確認してください。

ルールモードとDNSモードは、それぞれ異なる処理を担います。前者はリクエストの出力先を決め、後者は名前解決と応答方法に影響します。ドメインをDIRECTルールに追加しても、アプリが実際のIPアドレスを受け取れるとは限りません。同様に、ドメインをFake-IPフィルターに追加しても、自動的に直接接続されるわけではありません。LAN内の実際の名前解決と直接接続の両方が必要な場合は、2つの設定を別々に確認してください。

合成アドレスが対象機能に影響していると確認できた場合にだけ、フィルターを追加してください。元の設定をバックアップし、変更したドメインと症状を記録して、テストに成功してからルールを残しましょう。