Fake-IPモードでドメイン情報を保持する仕組み：DNSマッピング、適用場面と除外設定
DNS問い合わせから接続確立までを追い、仮想アドレスのマッピング、Fake-IPの適用条件、LAN互換性、fake-ip-filterの設定範囲を解説します。
1. Fake-IPと実アドレス解決の違い
Fake-IPを有効にすると、WebサイトのAレコードを問い合わせた際、アプリにはWebサーバーのグローバルIPではなく、198.18.0.2のようなアドレスが返ることがあります。これは通常、カーネルが動的に生成した仮想アドレスであり、この結果だけでDNS障害と判断すべきではありません。後続の接続に照合可能な識別情報を持たせ、カーネルがアクセス先のドメインを復元できるようにする仕組みです。
通常のDNS解決で実アドレスが返ると、アプリは宛先IPだけをネットワークスタックに渡すことがあります。複数のドメインが同じCDNアドレスを共有している場合、そのIPだけから元のドメインを特定するのは困難です。Fake-IPではDNS応答時に「ドメインと仮想アドレス」の対応付けを作成し、接続が同じカーネルに入るとマッピングからドメインを復元して、ルールマッチングと出力処理を行えます。
- Fake-IPはプロキシノードではありません：ローカルの処理経路で使うアドレス識別子であり、リモートサーバーの場所を示すものではありません。
- Fake-IPはDNS暗号化ではありません：上流DNSにUDP、DoH、DoTのどれを使うかは、別の設定項目です。
- Fake-IPはグローバルプロキシと同義ではありません：
mode: ruleでは、接続は引き続きルールに従ってダイレクト接続やプロキシなどの宛先へ振り分けられます。
198.18.0.0/16はネットワークベンチマーク用に予約された198.18.0.0/15のアドレス空間に含まれます。Webサイトの実際のグローバルアドレスでも、一般家庭のLAN向けアドレス帯でもありません。端末が接続するネットワークですでにこの範囲を使っている場合は、接管ルールを追加する前にルーティングの競合を解消してください。
2. DNS問い合わせから出力接続までの5段階
Fake-IPを理解するには、2つの経路を分けて考えることが重要です。DNS問い合わせがどこへ入るか、そして取得したアドレスへの接続がどこへ入るかです。両者が同じ有効なマッピングに結び付いて初めて、仮想アドレスが意味を持ちます。
- アプリが問い合わせを開始します。たとえばブラウザが
example.comのAレコードを要求すると、問い合わせはシステムリゾルバー、DNS転送、またはTUNのDNS接管を経由してカーネルに入ります。 - カーネルが仮想アドレスを割り当てます。ドメインがFake-IPの処理対象であれば、カーネルはアドレスプールから1つを返し、マッピングを保存します。本記事では流れを説明するため
198.18.0.2を使いますが、実際の割り当て値は固定ではありません。 - アプリが接続を確立します。アプリはこの仮想アドレスの宛先ポートへ接続します。たとえばHTTPSでは
443番ポートです。 - カーネルがドメインを照合してルールを適用します。接続を受け取ったカーネルはマッピングを使って
example.comを識別し、ドメインルールに利用できる情報を得ます。 - 選択した出力方式で処理します。ダイレクト接続では通常、実際の宛先アドレスを取得する必要があります。プロキシ出力では、ドメイン解決をリモートに任せる場合も、ローカルで行う場合もあり、プロトコル、ノード設定、カーネルの動作によって異なります。
アプリが example.com を問い合わせ
→ カーネルDNSが仮想アドレスを返す
→ アプリが仮想アドレス:443へ接続
→ 同じカーネルで example.com を照合
→ ルールにマッチ
→ ダイレクトまたはプロキシで出力したがって、「DNSがFake-IPを返した」ことは問い合わせ経路の一部が成功したことしか示さず、接続が接管されたことまでは証明しません。アプリが仮想アドレスを取得しても、カーネルを迂回して直接データを送信すれば、通常のネットワークはどのWebサイトへ届けるべきか分からず、接続タイムアウトになることがあります。
ドメインマッピングがあっても実DNS問い合わせが発生するのはなぜ？
Fake-IPを使うと、アプリはまず仮想応答を取得できますが、接続全体で実IPの問い合わせが一切発生しないとは限りません。ダイレクト接続、宛先IPを必要とするルール判定、プロキシサーバー自身のドメイン解決などで、解決処理が行われることがあります。ルールにno-resolveが付いているか、カーネルが該当するルールオプションに対応しているかも処理に影響します。「待ち時間の一部を減らす」ことを「すべてのDNS問い合わせをなくす」ことと解釈しないでください。
3. 有効化前にDNSと接続接管の範囲を確認する
Fake-IPは、透明な接管を必要とし、ドメインルールのマッチング情報を保持したい環境に適しています。たとえば、ルーティングとDNS接管を正しく設定したデスクトップのTUN環境です。すべてのアプリの通信問題を解決するための標準設定ではありません。
| 利用方式 | ドメイン情報の取得元 | 優先して確認する項目 |
|---|---|---|
| HTTPシステムプロキシ | プロキシリクエストには通常、対象ホスト名が含まれる | アプリがシステムプロキシに従っているかを確認する。端末全体のDNSが接管されているとは判断できない |
| TUNによる透過接管 | Fake-IPマッピングからドメインを復元できる | DNS問い合わせと仮想アドレスへの接続が同じカーネルに入っているか |
| LANゲートウェイ | ゲートウェイDNSがマッピングを作成する | 端末のDNS、ゲートウェイルート、戻り経路が一致しているか |
| アプリ内蔵の暗号化DNS | カーネルのDNSを迂回して実IPを直接取得する可能性がある | アプリのセキュアDNS、システムの暗号化DNS、既存VPNの設定 |
TUNは仮想ネットワークインターフェースと接管経路を提供し、Fake-IPはDNSマッピングを提供します。両者は別の層です。TUNを有効にしても、すべてのアプリのDoHリクエストが通常のDNS問い合わせに変わるわけではありません。DNSのenhanced-mode: fake-ipを有効にしても、システムの全ルートが自動的に設定されるわけではありません。
- クライアントのバージョン、カーネル名、カーネルバージョンを記録し、実行中のものが別のバックグラウンドインスタンスではないことを確認します。
- 現在有効な設定と、クライアントが個別に管理するオーバーライド断片を保存します。サブスクリプションの原文だけをバックアップすると、DNS設定が抜けることがあります。
- 他のVPN、ゲートウェイソフト、セキュリティソフトがDNSやルートを同時に変更していないか確認します。
- 初回検証ではDNSモードと必要な接管設定だけを変更し、ノード、プロキシグループ、ルール順序を同時に変更しないでください。
4. Fake-IP設定例とフィールドの範囲
mixed-port: 7890
mode: rule
allow-lan: false
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-mode: blacklist
fake-ip-filter:
- "localhost"
- "*.lan"
- "*.home.arpa"
nameserver:
- 1.1.1.12つのポートを混同しない
7890は例で使うHTTP/SOCKS混合プロキシポート、1053はカーネルがDNSを待ち受けるポートです。ブラウザのプロキシ設定にDNSポートを指定してはいけません。多くのシステムDNS設定画面では非標準ポートを直接指定できないため、この断片は明示的にポートを指定できる問い合わせツール向けであり、YAMLを読み込むだけでシステムDNSを自動接管するものではありません。
listen: 127.0.0.1:1053は待ち受けをローカル端末に限定します。LAN内の他の端末はこれをDNSサーバーとして利用できません。LANに提供する場合は、待ち受けアドレス、ファイアウォール、トラフィックルートを別途設計する必要があります。allow-lan: falseはプロキシ入口へのLANアクセスを制御する設定であり、DNS待ち受けアドレスのセキュリティ設定の代わりにはなりません。
フィルターモードはカーネルの対応状況に合わせる
fake-ip-filter-modeに対応するmihomoでは、例としてblacklistを明示的に選択しています。リストに一致するドメインにはFake-IPを返さず、実際の名前解決を行います。whitelistを選ぶとリストの意味が反転し、一致した項目だけにFake-IPを使用します。古いカーネルがモードフィールドに対応しているとは限らないため、未知のフィールドが無視されたことを設定成功と見なさないでください。
例のipv6: falseは今回のDNS検証範囲を絞るためのもので、OSのIPv6を無効化する設定ではありません。また、他の解決経路がAAAAレコードを返さないことを示すものでもありません。本番環境ではIPv6ルートと実際のカーネル対応状況を踏まえて再評価してください。その他のフィールドは設定リファレンスと照合しながら確認できます。
5. LAN互換性の問題と除外設定の選び方
一部のアプリは、単に接続を確立できる識別子ではなく、実際のアドレスを必要とします。たとえばNAS管理ツールはサーバーがローカルネットワーク内にあるか確認することがあり、印刷ツールはプロキシを経由しない検出コンポーネントに解決結果を渡すことがあります。IPアドレスを他の端末へ送信して利用するプログラムもあります。このような場合は、すべてのドメインを除外するより、特定のドメインだけ実アドレス解決にするほうが影響を管理しやすくなります。
Fake-IPからの除外はLAN用DNSの指定ではない
"*.home.arpa"をフィルターリストに追加すると、カーネルは実アドレスを問い合わせるようになるだけです。パブリックDNSは通常、家庭内ネットワークのホストレコードを知りません。NASの名前をルーターが提供している場合は、対応するドメインをルーターのDNSへ渡す必要があります。たとえばカーネルが対応するnameserver-policyで解決先を指定し、ルーターのDNSサービスに到達できることを確認します。
.localは通常mDNSに使われ、ユニキャストDNSサーバーへ通常の問い合わせを送る仕組みとは本質的に異なります。"*.local"をリストに追加しても、マルチキャストによる検出が自動的に復元されるわけではなく、カーネルがmDNSリレーになるわけでもありません。画面共有や印刷機器の検出に失敗する場合は、LANアクセス権限、マルチキャスト通信、TUNのルーティング範囲も確認してください。
- まずドメインを絞る：特定の端末だけに問題がある場合は、最初にその端末名を対象に検証し、範囲の広いワイルドカードをいきなり追加しないでください。
- 次に解決元を確認する：除外後は、信頼できるローカルDNSが返した実際のアドレスを取得できているか確認します。パブリックDNSから存在しないという応答を受けているだけでは不十分です。
- 最後に接続ルールを確認する：実アドレスが返っても、通信が自動的にダイレクト接続になるわけではありません。ルールによっては、そのドメインがプロキシグループへ送られることがあります。
クライアントによっては、リストのオーバーライドを置換方式またはマージ方式で処理します。カーネルにもバージョンに依存するデフォルト除外項目がある場合があります。変更後はエディターで追加した数行だけでなく、最終的に有効な設定を確認してください。1つの互換性問題を解消するためにすべてのドメインを除外すると、Fake-IPが実際に処理へ参加したか検証しにくくなります。
6. 問い合わせ、マッピング、ルール、出力の順に検証する
1. カーネルのDNS応答を単独で検証する
digをインストール済みのmacOS、Linuxなどの環境で、先ほどのローカル待ち受けアドレスに対して次を実行します：
dig @127.0.0.1 -p 1053 example.com A +shortドメインが除外されていなければ、設定した範囲内の仮想IPv4アドレスが返るはずです。具体的なアドレスは固定ではありません。タイムアウトする場合は、まずカーネルが起動しているか、DNSが有効か、1053が使用中でないかを確認します。実アドレスが返る場合は、フィルターモード、デフォルト除外項目、現在実行中の設定に変更が確実に反映されているかを確認してください。これは期待される動作の説明であり、本サイトによる実測記録ではありません。
2. 実際のアプリで接続接管を検証する
システムまたはアプリのDNSが予定した経路で接続されていることを確認したら、ブラウザでテスト用ドメインを開き、同時にクライアントの接続ログを確認します。「Webページが開いたか」だけでなく、対象ドメイン、適用ルール、出力ポリシー、接続エラーを確認してください。カーネルに対してdigを1回実行しても、ブラウザが同じ解決経路を自動的に使うわけではありません。
明示的なHTTPプロキシリクエストには通常ドメインが含まれるため、「プロキシポート経由でアクセスできた」ことはそのプロキシ経路を検証できるだけで、TUNのFake-IP照合が正常だと単独で証明するものではありません。同様に、仮想アドレスへpingを実行した結果からHTTPSの利用可否を判断することもできません。ICMPとTCP接続では処理が異なります。
3. どの段階でエラーが発生したかを切り分ける
| 症状 | 優先して確認する項目 | 次に確認すること |
|---|---|---|
| 仮想アドレスは取得できるが、接続ログがない | アプリがカーネルを迂回して接続していないか | TUNのルート、アプリの除外設定、他のVPNを確認する |
| カーネル再起動後、一部のWebサイトに接続できない | アプリのキャッシュに古い仮想アドレスが残っていないか | 古い接続を閉じ、DNSキャッシュを更新して再問い合わせする |
| NASのドメインを除外しても解決できない | そのドメインがローカルレコードを把握するDNSへ渡されているか | 振り分け解決とルーターDNSの応答を確認する |
| ドメインとルールは正しいが、出力がタイムアウトする | ノード、ダイレクト接続先、出力側の名前解決が利用可能か | 経路を切り分けてトラブルシューティングし、フィルターリストをさらに広げない |
4. キャッシュを消去してから単一変数で再テストする
Windowsではipconfig /flushdnsを使ってシステムDNSキャッシュを消去できます。systemd-resolvedを使うLinuxでは、resolvectl flush-cachesを実行できます。ブラウザ、アプリ、カーネルが別のキャッシュを持つ場合もあり、システムコマンドですべての層が消去されるわけではありません。テスト対象アプリの古い接続を閉じてからリクエストを再実行すると、過去の結果による影響を抑えられます。
対応するカーネルではprofile.store-fake-ipを使ってマッピングを永続化できますが、これはルーティング設定の代わりにはならず、外部キャッシュとマッピングが常に同期することも保証しません。アドレスプールを変更したりカーネルキャッシュを消去したりした後は、アプリに再解決させてください。
7. よくある質問と切り戻し方法
Fake-IPで、すべてのドメインルールを確実にマッチさせられますか？
いいえ。アプリがIPへ直接アクセスする、内蔵DNSでカーネルを迂回する、マッピングが失われる、またはより前方のルールに先に捕捉されるなどの理由で、マッチングに影響が出ることがあります。トラフィック嗅探でプロトコルからホスト名情報を補える場合もありますが、これは独立した機能であり、暗号化プロトコルや標準外プロトコルで常に有効とは限りません。
Fake-IPを有効にすると、すべてのドメインがプロキシサーバーで解決されますか？
いいえ。アプリに仮想アドレスが見えていることは、ローカルDNS応答にマッピング方式が使われたことを示すだけです。実際の名前解決をローカルとリモートのどちらで行うかは、ルール、出力プロトコル、ノード設定によって決まります。プロキシサーバー自身のドメインにも利用可能な解決経路が必要で、まだ確立していないプロキシ接続に依存して循環状態を作らないよう注意してください。
フィルターリストを変更したら、サブスクリプションを更新する必要がありますか？
通常はアプリの設定を反映するかカーネルを再読み込みし、アプリに再問い合わせさせれば十分で、サブスクリプション更新を必須手順にする必要はありません。サブスクリプションが生成したファイルを直接編集すると、次回更新時に変更が上書きされることがあります。クライアントが提供する永続オーバーライドの入口で変更を保存し、その後、最終設定を確認してリストの意味が意図どおりか確かめてください。
広範囲で接続に失敗した場合は、まず保存しておいたDNSと接管設定へ戻し、その後にシステムとアプリのキャッシュを処理します。モードだけをredir-hostへ戻して古い仮想アドレスのキャッシュを残すと、障害が一時的に続くことがあります。クライアントを終了するだけでシステムプロキシやDNSが停止済みのローカルポートを指したままにしても、新たな通信断が発生します。
トラブルシューティング情報を共有する際は、クライアントとカーネルのバージョン、問い合わせコマンドと結果、適用ルール、エラー発生時刻を残し、サブスクリプションURL、トークン、ノードの認証情報を削除してください。検証すべきなのは「問い合わせと接続が同じカーネルに入り、ドメインマッピングが有効で、ルールと出力が想定どおり動作すること」であり、DNS結果を特定のアドレス帯にすることだけではありません。