Fake-IPとredir-hostの違い｜mihomoのDNS強化モードの仕組みと使い分け

DNS強化モードで変わること

mihomoの設定では、dns.enhanced-modeによって内蔵DNSのアドレス検索方法と、その後の接続でドメイン名を関連付ける方法が決まります。主な値はfake-ipとredir-hostです。これはプロキシプロトコルではなく、ルールモードやグローバルモード、TUNの有効・無効とも別の設定です。

2つのモードを理解するには、まず「アプリがドメイン名を問い合わせる」「OSが接続を開始する」「コアがルールに基づいて出先を選ぶ」という3つの動作を分けて考えます。DNSが返すアドレスが決めるのは、この流れの一部だけです。最終的に直接接続するかプロキシを使うかは、ルール、プロキシグループ、利用可能な出先によって決まります。

Fake-IP：仮想アドレスでドメイン名との対応を維持

DNS問い合わせから接続まで

1. アプリが、DNS処理をmihomoに引き渡された状態でドメイン名のAレコードを問い合わせます。
2. mihomoは設定されたアドレスプールから仮想IPv4アドレスを割り当て、「ドメイン名と仮想アドレス」の対応を保存します。
3. アプリは受け取ったアドレスに接続します。この接続は、保存された対応関係を参照できる同じコアへ再び届く必要があります。
4. コアは仮想アドレスからドメイン名を特定してルールを照合し、選択した出先から接続先へアクセスします。

たとえば、アドレスプールに198.18.0.1/16を設定すると、アプリにはこの範囲内のアドレスが返される場合があります。この範囲はベンチマーク用に予約されたアドレス空間で、接続先サイトのグローバルIPでもプロキシサーバーのアドレスでもありません。サイトの固定IPとして手動登録しないでください。

Fake-IPの目的はサイトの内容を偽装することではなく、接続がコアに届くまでドメイン名の情報を保つことです。複数のサイトが同じCDNの実アドレスを共有していても、それぞれの仮想アドレスから個別のドメイン名を特定できるため、ドメイン名ベースのルールを適用しやすくなります。

DNSの待ち時間を短縮できる理由

仮想アドレスを返す際、接続先ドメインの実際のAレコードを先に待つ必要がないのが一般的です。ドメイン名を渡せるプロキシ出先では、コアから名前をリモート側へ渡して処理できるため、クライアント側で実アドレスの解決を待つ工程を減らせる場合があります。短縮されるのは一部の事前待ち時間であり、すべての通信でDNSが不要になるわけではありません。

• 直接接続のルールに一致：通常、直接接続を確立するにはローカル側で接続先の実アドレスを取得する必要があります。
• IP系ルールに一致：ルールの種類や順序、no-resolveを使うかどうかによって、判定時に名前解決が必要になる場合があります。
• プロキシノードにドメイン名を指定：ノード自体の名前解決も必要です。接続先サイトのFake-IP対応情報では解決できません。
• 最初のハンドシェイクとリモート側のネットワーク：TCP、TLS、ノードの負荷、リモート側のDNSが引き続き主な遅延要因になることがあります。

そのため、DNS問い合わせが速くなっても、ウェブページの表示が必ず速くなるとは限りません。ノードの遅延テストをDNSの所要時間と混同せず、ブラウザーで初めて開いたときの体感だけでモードの優劣を判断しないでください。

redir-host：実アドレスを先に返す

redir-hostでは、内蔵DNSが上流DNSへ問い合わせ、実際の解決結果をアプリに返します。コアはDNSキャッシュにあるドメイン名とアドレスの対応を、後続の接続処理に利用できます。ただし、複数のドメインが同じIPを共有する場合などは、対応関係の特定が難しくなることがあります。スニッフィングでドメイン名を補足できる場合もありますが、すべてのプロトコルを識別できるわけではありません。

ここでいう「実アドレス」とは、上流DNSが返したアドレスを指します。接続可能であることや最適なアドレスであること、ネットワーク環境の影響を受けていないことを保証するものではありません。上流DNSの選択、DNSの振り分け、キャッシュ、出先までの経路は、それぞれ個別に確認が必要です。

最小限の設定とDNSの処理範囲

以下は各項目の意味を説明するためのDNS設定例であり、完全なサブスクリプション設定ではありません。ローカルの127.0.0.1:1053で待ち受け、平文の上流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"
    - "+.local"
    - "+.home.arpa"
  nameserver:
    - 223.5.5.5

listenは待ち受け先を指定するだけで、システムのDNS設定を自動で変更するものではありません。一般的なシステムDNS設定で指定できるのは通常サーバーのIPアドレスだけで、ポート番号は入力できません。IPアドレスのみ受け付ける欄に127.0.0.1:1053をそのまま入力しないでください。クライアントのDNS処理、TUNのDNSハイジャック、またはローカル転送を使い、問い合わせをこの待ち受け先へ届ける必要があります。

TUNとシステムプロキシの違い

TUNはシステムのルーティングから送られるIP通信を受け取り、DNS強化モードはDNSを処理します。役割はそれぞれ異なります。TUN設定のdns-hijackでは、条件に合うDNS通信を引き継げます。たとえばany:53は一般的なDNS問い合わせを対象とします。TCP DNSは対応する構文を別途考慮してください。ポート443のDoHは、53番ポートのハイジャックを設定しただけでは内蔵DNSへの問い合わせに切り替わりません。

システムHTTPプロキシだけを有効にしている場合、接続先のドメイン名をプロキシへ直接渡すアプリもあれば、ローカルで名前解決するアプリもあります。このとき実IPが表示されても、設定失敗とは限りません。一方、アプリがFake-IPを受け取った後、処理を引き継がれない経路で仮想アドレスへ直接接続すると、タイムアウトすることがあります。

fake-ip-filter：必要なドメインだけ例外にする

fake-ip-filterは、ドメインごとにアドレスの返し方を変える設定です。広告ブロックリストでも出先ルールでもありません。上記のblacklistモードでは、リストに一致するドメインにFake-IPを割り当てず、実際の解決結果を返します。whitelistに変更するとリストの意味が逆になるため、ブラックリストの内容をそのまま流用できません。

• localhostは完全一致するドメイン名の例です。
• +.lanはそのドメインとサブドメインを対象にします。通常の文字列部分一致ではありません。
• +.home.arpaは家庭内ネットワークのドメインに使えますが、その名前を解決できるDNSが必要です。
• +.localが対象にするのは、実際に内蔵DNSへ届いた問い合わせだけです。mDNSは通常UDP 5353を使うため、マルチキャストによるデバイス検出をこのリストだけで完全に処理することはできません。

ドメインをフィルターに追加しても、自動的に直接接続になるわけではありません。LAN内サービスへの接続が目的なら、該当するルールがDIRECTを選ぶこと、プライベートアドレスへルーティングできること、適切な上流DNSまたはnameserver-policyで内部レコードを取得できることも確認してください。フィルターが扱うのは「仮想アドレスと実アドレスのどちらを返すか」だけです。

問題を一つ解消するために広すぎるサフィックスを追加したり、すべてのドメインに実アドレスを返したりするのはおすすめしません。まず接続ログから実際に失敗しているドメイン名を特定し、必要最小限の範囲だけ例外にしてください。サブスクリプションに既存のフィルター項目がある場合は、クライアントの上書き方法がマージか置換かも確認しましょう。

そのまま有効にするのに注意が必要なアプリとネットワーク

実IPに依存するツール

ネットワーク診断、IPの所在地判定、解決したアドレスをアクセス制御リストへ登録するプログラムなどは、Fake-IPを実サーバーのアドレスと誤認することがあります。その場合、結果は本来の意味を失います。実アドレスを調べるには、対象ドメインを実アドレスで解決するか、管理されたテスト環境でredir-hostに切り替えてください。

LAN内のデバイス検出と企業内サービス

NAS、プリンター、画面ミラーリング、企業内ドメインは、ローカルDNS、マルチキャスト、ブロードキャスト、専用ルートに依存することがよくあります。実アドレスを返すことは必要条件の一つにすぎません。企業VPNのスプリットDNS、TUNのルート、プライベートアドレス帯が競合する場合は、DNSを引き継ぐ範囲なども調整が必要です。フィルターだけでは解決できません。

解決結果を別の端末へ渡すプログラム

プログラムがローカルで名前解決し、そのアドレスを別の端末へ送って接続させる場合、その端末には通常、対応するFake-IP情報がありません。一部のP2P、メディア、制御系アプリでこのような動作が見られることはありますが、ゲーム、動画、UDPを使うアプリすべてが非対応という意味ではありません。実際のドメイン名、接続経路、エラーログをもとに判断してください。

また、実IPをハードコードしたアプリはドメイン名を問い合わせないため、Fake-IPフィルターは適用されません。この場合は、ドメインの例外追加ではなく、IPルール、UDP対応、ルーティング、ファイアウォールを確認してください。

動作確認とトラブル対処：問い合わせ・対応情報・出先を確認

1. 現在の設定を確認：読み込まれているProfileと、最終的に適用されたdns.enhanced-modeを確認します。リモートサブスクリプションの更新で直接編集したファイルが上書きされることがあるため、クライアントの永続的なオーバーライド機能を使うのがおすすめです。
2. 待ち受け先へ直接問い合わせ：システムにdigがインストールされている場合は、次のコマンドでシステムの既定DNSを経由せず、例として設定した待ち受けポートへ直接問い合わせられます。
3. 接続ログを確認：同じドメインへアクセスし、コアが接続を記録しているか、ドメイン名を特定できているか、どのルールに一致したか、最終的にどの出先が使われたかを確認します。
4. DNSを迂回する経路を確認：直接問い合わせは正常なのにアプリの動作が異なる場合は、ブラウザーのセキュアDNS、アプリ内蔵DoH、システムキャッシュ、他のVPNを確認してください。
5. 一つずつ比較：まず問題のドメインだけをフィルターに追加し、それでも解決しない場合にredir-hostと比較します。一度に変更する項目は一つにし、元に戻せる設定のコピーを残してください。

dig @127.0.0.1 -p 1053 example.com A

上記のFake-IP設定では、フィルターに一致しないAレコードの問い合わせに、設定したアドレスプール内のアドレスが返されるはずです。redir-hostへ切り替えた場合は、上流DNSの実際の応答が返されます。このコマンドで確認できるのはDNSの待ち受けと応答値だけで、TUNでの通信引き継ぎやプロキシ出先の正常動作までは確認できません。

モードを切り替えても、アプリに以前の仮想アドレスが残っている場合があります。Windowsではipconfig /flushdnsでシステムDNSキャッシュを消去できますが、ブラウザーやアプリのキャッシュを解放するには再起動が必要なこともあります。対応情報だけを消してアプリが古いFake-IPを使い続けると、新しい接続も失敗する可能性があります。

速度を比較する場合は、同じネットワーク、ノード、対象ドメイン、出先ルールを使い、キャッシュがない状態とある状態の両方を記録します。たとえば各モードで10回ずつ問い合わせ、初回の結果を分けて記録したうえで、残りの中央値を比較します。これはテスト方法の例であり、このサイトによる性能測定結果ではありません。DNS、接続確立、ページ読み込みの時間は分けて記録してください。

モードの選び方と設定の保持

• Fake-IPを検討する場合：DNSとアプリの通信を安定して同じmihomoコアへ通せること、ドメイン名を明確に関連付ける必要があること、アプリが実アドレスに依存しないこと。
• redir-hostを検討する場合：実IPが必要なワークフロー、互換性の優先、または仮想アドレスへの接続を確実にコアへ戻せないネットワーク環境。
• 必要なドメインだけをフィルター：ほとんどのアプリは正常に動作し、一部の内部ドメインや特定のプログラムだけに問題があり、実アドレスが必要だと特定できている場合。

再起動後も対応情報をできるだけ保持したい場合は、設定のprofile.store-fake-ipを確認してください。永続化によって対応情報の消失による問題を減らせますが、誤ったルーティングは直せず、設定の切り替え、アドレスプールの変更、データの消去後も古いアドレスが使えるとは限りません。最終的には、実行中の設定、DNS応答値、接続ログが一致していることを確認してください。