Fake-IPモードの仕組み｜198.18予約アドレス・fake-ip-filter・利用時の注意点

Fake-IPの仕組み：先に仮想アドレスを返し、その後に実際の接続を処理

Fake-IPを有効にすると、ドメインを検索した際に198.18.x.xが返されることがあります。通常はDNSのエラーではなく、カーネルがローカルでのマッピング用アドレスを返しています。仕組みを理解するには、2つの処理を分けて考えましょう。DNSの応答は「アプリが次にどのアドレスへ接続するか」を示し、プロキシルールは「その接続をどの経路に流すか」を決めます。連携はしますが、同じ設定ではありません。

この記事の設定例は、Clash Metaから発展したmihomoカーネルを対象にしています。クライアントによって画面上の項目名や設定のマージ方法は異なり、旧版のClashカーネルではDNSの拡張項目に対応していない場合もあります。変更前に、エディターに保存されたファイルだけでなく、クライアントのカーネル情報と実行中の設定で実際の適用内容を確認してください。

ドメインへのアクセスはどのように処理される？

アプリがexample.comのIPv4アドレスを問い合わせると、リクエストはmihomoのDNSサービスに届きます。
カーネルはFake-IPアドレスプールからアドレスを割り当て、「ドメイン名 ↔ 仮想アドレス」の対応関係を作成して、仮想アドレスをアプリに返します。
アプリはそのアドレスに接続します。この接続は、適切に設定されたTUNルートなどを通じて、同じカーネルに再び取り込まれる必要があります。
カーネルは対応関係からドメイン名を復元し、ルールを照合したうえで、直接接続またはプロキシ経由で実際の接続先に接続します。

主な利点は、Fake-IPを割り当てられる問い合わせなら、DNSの応答時に上流DNSから実アドレスが返るのを待たずに済むことです。また、ドメイン名をルールによる振り分けまで保持できます。ただし、その後の直接接続、IPベースのルール照合、一部のプロキシプロトコルでは、実際の名前解決が必要になる場合があります。動作はルール、接続先、カーネルの仕様によって異なります。「DNSの応答が速い」ことは、「すべてのWebページが速くなる」ことを意味しません。

198.18.0.1/16とは？アドレスプールと予約済みネットワーク

198.18.0.0/15はネットワーク機器の性能評価に使われる特殊用途のIPv4ネットワークです。範囲は198.18.0.0から198.19.255.255までで、通常のWebサイトが使うグローバルルーティング可能なアドレスではありません。一般的な設定例の198.18.0.1/16は、そのうちの/16をFake-IPのアドレスプールとして使います。/16と/15全体を混同しないでください。

設定に198.18.0.1/16と書かれていても、すべてのドメインに198.18.0.1が返されるわけではありません。カーネルがアドレスプールと対応関係を管理し、ドメインごとに異なるアドレスを割り当てます。このアドレスはノードサーバーのものではないため、ノードの速度測定に使ったり、サブスクリプションURL欄に入力したりしないでください。

予約済みアドレスが表示された場合：すぐにDNSを変更せず、Fake-IPの応答によるものか確認してください。
企業ネットワークや検証環境で同じネットワークを使用している場合：ルートの競合が起きることがあります。ルーティングテーブルとアドレスプールの設計を確認してください。
アドレスプールを変更する場合：TUNルート、透過型ルーターの転送、アプリのキャッシュも合わせて確認してください。YAMLの1行だけを変更して終わりにしないでください。

「実際のIPらしく見せる」ために、アドレスプールを安易に192.168.1.0/24へ変更しないでください。自宅のルーター、プリンター、NASが使うネットワークと重複する可能性があります。予約済みアドレスはマッピングを分離するためのもので、画面上の数字を見慣れたものにするためではありません。

Fake-IPとredir-host：DNSモードの選び方

redir-hostは通常、上流DNSが返した実アドレスをアプリに返し、DNSマッピングなどを利用して接続を処理します。一方、fake-ipは主にローカルのマッピングアドレスを返します。ここでいうモードはDNS拡張モードであり、クライアントのホーム画面にある「ルール、グローバル、ダイレクト」とは別の設定です。

比較項目	fake-ip	redir-host
アプリに返されるAレコード	通常はアドレスプール内のマッピングアドレス	通常は上流DNSが返す実際のIPv4アドレス
最初のDNS応答	先にマッピングを割り当て、上流DNSの応答待ちを減らせる	キャッシュにない場合は、通常、実際の名前解決を待つ
接続を取り込むための要件	仮想アドレスへの接続を、マッピングを保持するカーネルに戻す必要がある	適切な接続の取り込みは必要だが、実アドレスは通常のネットワークでも認識できる
よくある互換性の問題	アドレス確認、LAN内のデバイス検出、接続の取り込みを回避するプログラム	共有IP、DNSキャッシュ、ドメインとの関連付けが不完全なケースなど
まず試すのに向いている環境	通信が適切に取り込まれ、日常のインターネット利用でドメインベースのルールを使う環境	実際の名前解決結果に依存し、Fake-IPの例外が多い環境

どちらか一方に決める必要はありません。日常的なブラウジングやTUNでの通信取り込みなら、まずFake-IPを使い、問題が確認されたサービスだけ例外に設定できます。企業VPN、複雑なLAN、アドレス確認に依存する業務では、実アドレスを返すモードのほうが管理しやすいか検証してみましょう。判断基準は一度のDNS問い合わせ時間ではなく、実際のアクセス、ログ、ルートが一致しているかどうかです。

mihomoのDNS設定：最小構成と確認方法

以下はdns設定の一部であり、完全なサブスクリプション設定ではありません。既存の設定にマージし、トップレベルのdns:が重複しないようにしてください。例では検証用に127.0.0.1:1053で待ち受けます。この設定だけでシステムのDNSがこのポートに変更されたり、TUNが有効になったりすることはありません。

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'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

nameserverは上流DNSの例です。2つとも現在のネットワークから接続できるとは限らず、ここで暗号化DNSを設定しているわけでもありません。ネットワーク環境と名前解決の要件に合わせて上流DNSを選んでください。DoHやDoTを使う場合は、サーバー名の事前解決、接続性、既存のDNS振り分けも考慮し、リクエストがループしないようにしてください。

まずカーネルをテストし、その後にシステム側の経路を確認

設定を保存し、カーネルへの読み込みが成功したことを確認してから、digがインストールされた環境で次のコマンドを実行します。ここでは-p 1053を指定してテストポートを明示し、システムが別のDNSサービスに問い合わせてしまうのを防ぎます。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com A +short

ほかのフィルターやポリシーが適用されていない場合、最初のコマンドでは回答欄に198.18.x.xが表示され、2つ目のコマンドではアドレスだけが出力されます。実際に割り当てられる値はカーネルの実行状態によって異なり、スクリーンショットと完全に一致する必要はありません。接続が拒否された場合は、ノードを変更する前にDNS機能、待ち受けポート、カーネルログを確認してください。

カーネルに直接問い合わせ、期待どおりのAレコードが返ることを確認します。
クライアントのTUNによるDNSリダイレクト、またはシステムDNSの転送先が、実際にカーネルを指しているか確認します。
アプリから新しい接続を開始し、接続パネルでドメイン名、適用されたルール、接続先を確認します。
古い結果が残っている場合は、アプリとシステムのDNSキャッシュを消去し、新しい接続で再テストします。

fake-ip-filterの書き方：実アドレスを返す設定とダイレクト接続は別

例で明示しているblacklistモードでは、fake-ip-filterに一致したドメインにはFake-IPを割り当てず、実際の名前解決を行います。この項目に対応するmihomoにはほかのフィルターモードもあり、意味が逆になる場合があります。設定を移行するときは、フィルターモードとリストをセットで確認してください。旧カーネルで未対応の項目と表示された場合は、該当カーネルのドキュメントに従って調整し、エラーを消すだけでなく設定の意味も確認しましょう。

例の'+.lan'はlanとそのサブドメインに適用され、'+ .local'も同様です。これはmihomoのドメインマッチ記法であり、自由に組み合わせて使える正規表現ではありません。保守しやすく、YAMLの特殊文字による解析エラーも避けやすいため、引用符を付けたままにすることをおすすめします。

3つの設定を分けて考える

どのアドレスを返すか：Fake-IPモードとフィルターポリシーで決まります。
どのDNSに問い合わせるか：上流DNSやnameserver-policyなどの設定で決まります。
接続をどこへ流すか：rulesとプロキシグループの選択で決まります。

そのため、NASのドメインをフィルターリストに追加しても、自動的に自宅のルーターへ問い合わせるようになったり、DIRECTルールが追加されたりするわけではありません。ルーターのDNSでしか解決できないドメインなら、正しいLAN内DNSへ問い合わせを送る設定が必要です。また、接続先ネットワークへ直接到達できることも確認してください。

リストを管理するときは、一度に追加する範囲を必要なサービスのドメインに限定し、変更前後の名前解決結果とアクセス結果を記録しましょう。対象が広すぎる公開ドメインのサフィックスを追加すると、Fake-IPが適している多くのリクエストが実アドレスでの解決に切り替わり、問題の切り分けも難しくなります。

LANやゲームでの利用：実際に問題が起きた場合に例外を追加

NAS、プリンター、.localデバイスの検出

LAN内サービスへのアクセスには、一般に2つの方法があります。1つはルーターのユニキャストDNSでデバイス名を解決する方法、もう1つはmDNSでローカルネットワーク上のデバイスを検出する方法です。.localはmDNSでよく使われ、通常はUDPの5353を使用します。一般的なDNSの53ポートとは異なります。+.localをフィルターリストに追加しても、マルチキャストによる検出の問題がすべて解決するわけではありません。

NASのLAN内IPアドレスに直接アクセスできるのにホスト名では失敗する場合は、まず名前解決の経路を確認してください。デバイス一覧にまったく表示されない場合は、ファイアウォール、ネットワーク分離、マルチキャスト、TUNルートも調べる必要があります。問題が起きているレイヤーに合わせて、確認方法を変えましょう。

ゲームのログイン、対戦時のUDP、遅延表示

ゲームは、ドメインの名前解決結果を地域判定、サーバー一覧、接続確認、遅延表示などに使うことがあります。予約済みアドレスに対応できない確認処理もあるため、影響のあるドメインだけ実アドレスで解決するほうが、Fake-IP全体を無効にするより問題を特定しやすくなります。

ログインできない：ログイン用ドメインの名前解決、HTTPS接続、ルールの適用状況を確認してください。すぐにUDPが原因だと決めつけないでください。
ログインできるが対戦に参加できない：ゲームのUDP通信が取り込まれているか、ノードと接続先が必要なUDP通信に対応しているか確認してください。
遅延表示がおかしいがプレイはできる：ゲームがICMPや専用の確認用ドメインを使っていないか確認してください。表示値が対戦時の通信経路を示しているとは限りません。
モードを切り替えた後だけ問題が起きる：ゲームとランチャーを完全に終了し、キャッシュを消去してから接続し直してください。

すべてのゲーム関連ドメインを最初からフィルターリストに登録するのは避けてください。また、「UDPを許可すれば低遅延になる」とも限りません。Fake-IPが処理するのはアドレスのマッピングです。通信距離、接続先の混雑、NATタイプ、ゲームサーバーの状態は別の要因です。

Fake-IPで接続できないときの確認手順

確認のたびに変更する項目は1つだけにし、実行ログを残してください。以下のように設定から接続まで順に調べるほうが、グローバルモードを何度も切り替えるより効率的です。

実行中の設定を確認：現在の設定でenhanced-modeがfake-ipになっていること、サブスクリプションの更新でローカルの変更が上書きされていないこと、カーネルの設定読み込みでエラーが発生していないことを確認します。
問い合わせ先を確認：まず127.0.0.1:1053に直接問い合わせ、その結果をシステムやブラウザーの結果と比較します。ブラウザーのセキュアDNSやアプリ内蔵のDoHによって、想定したシステムの名前解決経路を迂回する場合があります。
通信の取り込み範囲を確認：一般的なTUNによるDNSリダイレクトは、従来のDNS通信を対象に設定することが多く、HTTPSを使う暗号化DNSをすべて通常の53番ポートの問い合わせとして自動認識できるわけではありません。アプリが仮想アドレスを受け取った後の接続も、カーネルに取り込まれる必要があります。
マッピングとキャッシュを確認：カーネルの再起動、設定の切り替え、アドレスプールの変更後も、アプリが古い仮想アドレスを保持していることがあります。まずキャッシュを消去して関連アプリを再起動し、その後、カーネルのFake-IPマッピングの永続化設定を調整する必要があるか判断してください。
ルールを確認：ドメイン名を含む接続が誤った接続先に流れる場合は、DNSだけでなくルールの順序とプロキシグループも確認してください。宛先IPに依存するルールでは、実際の名前解決が必要になることもあります。
IPv4とIPv6を確認：AレコードとAAAAレコードを個別にテストし、IPv6通信が取り込まれているか確認してください。IPv4の問い合わせが正常でも、IPv6の経路が正しく設定されているとは限りません。

最終的には、DNSがどこから入り、フィルター項目がなぜ必要で、実際の名前解決をどこに任せ、どのルールで接続を振り分けるかを説明できる設定を残してください。Fake-IPの利点は名前解決の待ち時間を減らし、ドメインとの関連付けを維持することです。ルーティング、ルール、ネットワーク品質の確認に取って代わるものではありません。