Fake-IPの仕組み：DNS応答を置き換えてドメイン名を保つ

Clash Verge RevでFake-IPを使う前に、DNSの名前解決とプロキシの役割を分けて考えましょう。DNSはドメイン名をIPアドレスに変換し、プロキシコアは接続をルールに照合して、直接接続するかプロキシ経由にするかを決めます。Fake-IPはDNS応答をローカルで置き換える機能です。Webサイトの実際のIPアドレスを変更するものでも、通信を暗号化するものでもありません。

mihomoのFake-IPモードでは、名前解決の問い合わせに対して、通常は198.18.0.0/16の範囲にある仮想アドレスを返します。アプリがそのアドレスに接続すると、コアは保存してある仮想アドレスとドメイン名の対応関係を参照し、ドメインルールを適用して接続先を決めます。そのため、接続先IPだけでは判定しにくい通信でも、ドメイン名に基づくルールを利用しやすくなります。

ただし、Fake-IPを有効にしただけで、Windows上のすべてのDNS問い合わせが自動的にClashへ届くわけではありません。Clash Verge RevのDNS機能、TUNのDNS取り込み、WindowsやブラウザーのDNS設定など、実際の問い合わせ経路が関係します。画面の設定が有効になっていることと、対象アプリがFake-IPを受け取っていることは別々に確認してください。

項目役割確認時の注意
Clash Verge Rev設定とmihomoコアを管理するGUIクライアント画面上のクライアント版と、実際に動くコアの情報は別です
mihomo DNSDNS問い合わせを処理し、Fake-IPなどの応答を返すコアがDNS設定を読み込んでいるか確認します
TUN仮想NICを使って対応するIP通信をコアに取り込むDNSポート53の取り込み設定や管理者権限も関係します
Windows・アプリDNS問い合わせを発生させる側独自の暗号化DNSやキャッシュが経路を変える場合があります

変更前の確認：コア、設定の管理元、TUNの状態

最初にClash Verge Revを起動し、設定画面またはログ画面で使用中のコアがmihomoであることを確認します。Fake-IPやDNS関連の項目はコアの実装とバージョンに依存します。GUIが設定を保存できても、コアが未対応の項目を読み込めるとは限りません。起動時ログにYAML解析エラーや未知のフィールドに関する警告がないかも確認してください。

次に、現在の設定がローカルファイルかリモートサブスクリプションかを確認します。リモート設定を更新すると、生成された設定内容が再取得され、手作業の変更が上書きされることがあります。設定の編集方法はClash Verge Revのバージョンや設定の管理方法で異なるため、画面にあるDNS設定またはオーバーライド機能を優先してください。設定ファイルを直接調整する場合は、元のファイルを別名で保存し、変更箇所だけを統合します。

DNSを取り込む経路を決める

ブラウザーなどシステムプロキシを利用するアプリだけを確認する場合と、Windows上のより広い範囲の通信を取り込む場合では、必要な設定が異なります。システムプロキシは、アプリがWindowsのプロキシ設定に従う場合に有効です。一方、TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。Fake-IPをWindows全体のDNS処理に適用したい場合は、TUNが有効で、DNS問い合わせもコアに届く構成になっているかを確認します。

  • ほかのVPNやプロキシクライアントを同時に動かさず、まず競合要因を減らします。
  • TUNを利用する場合は、Clash Verge Revを管理者権限で起動する必要があるか、クライアントの案内に従って確認します。
  • Windowsのネットワークアダプターやルーティングを手作業で変更する前に、クライアントが提供するTUN設定を確認します。
  • ブラウザー独自のセキュアDNS（DoH）が有効な場合、診断中だけ一時的に無効にして問い合わせ経路を統一します。

DNSの経路が不明なまま複数の設定を変更すると、Fake-IPの設定ミスと、Windowsやブラウザー側の問い合わせ経路の違いを区別しにくくなります。まず現在の構成を確認し、設定変更は一度に一つずつ行ってください。

Clash Verge RevでFake-IPを設定する

Clash Verge Revの画面構成や項目名はリリースによって異なる場合があります。DNS設定がGUIに表示される場合は、その画面でDNSを有効にし、強化モードとしてFake-IPを選択します。DNSのリスニングアドレス、Fake-IPの範囲、除外ドメインを編集できる場合もあります。設定を保存しただけで終わらず、現在選択中のプロファイルに反映されていることと、コアが新しい設定で再起動したことを確認してください。

GUIから該当項目を設定できず、設定のオーバーライドが利用できる場合は、次のようなmihomo設定を参考にします。これはDNS部分の例であり、単独で動作する完全な設定ファイルではありません。既存のdns:ブロックがあるときは、同じキーを二重に追加せず、必要な項目を既存のブロックへ統合してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

enableはコアのDNS機能を有効にし、enhanced-modeは応答方式をFake-IPにします。listenはDNSサービスの待ち受け先です。この例ではローカル端末から利用する想定で、ポートは1053にしています。実際のポートは既存設定やクライアントの構成に合わせてください。nameserverは通常の名前解決に使う上流DNSサーバーの例であり、利用できるDNSサーバーはネットワーク環境やポリシーに合わせて選びます。

Windows全体の問い合わせをTUN経由で取り込む構成では、TUN設定側のDNS取り込みも確認します。mihomoでは、たとえば次のようにDNSポート53の問い合わせを取り込む設定があります。

tun:
  enable: true
  dns-hijack:
    - any:53
    - tcp://any:53

この例はTUN設定の一部です。実際に使う際は、現在のtun:ブロックへ必要な値を統合し、コアのバージョンが該当項目に対応していることを確認します。すでにTUN設定がある場合、ブロック全体を置き換えないでください。また、このDNS取り込み例はアプリ独自のHTTPS経由DNS（DoH）やTLS経由DNS（DoT）を一律に捕捉する設定ではありません。

設定を反映して動作を確認する

ここからは設定の変更、コアの再読み込み、DNS応答の確認を順に行います。確認中は、ネットワークの変化を把握しやすいように、別のVPNやDNS変更ツールを停止しておきます。設定を反映した直後は、以前のDNSキャッシュが残ることがあるため、新しい問い合わせを発生させて結果を見てください。

  1. 現在のプロファイルと設定をバックアップし、DNSを有効にしてFake-IPを選択します。YAMLを使う場合は、既存のDNS設定と統合し、インデントとキーの重複を確認します。
  2. TUNを使ってWindowsのDNS問い合わせを取り込む場合は、TUNを有効にし、必要なら管理者権限でClash Verge Revを再起動します。クライアントが仮想アダプターの作成やアクセス許可を求めた場合は、表示内容を確認して操作します。
  3. プロファイルを再適用するか、コアを再起動します。ログに設定の解析エラー、DNSの起動失敗、ポートの使用中を示すメッセージがないことを確認してください。
  4. DNSのlistenを127.0.0.1:1053に設定した例では、Windowsのコマンドプロンプトで次を実行します。環境によってはnslookupのポート指定形式が異なるため、エラーになる場合はクライアントの接続ログとTUN経由の確認も併用します。
nslookup -port=1053 example.com 127.0.0.1

DNS問い合わせがmihomoのFake-IP DNSに届いていれば、応答アドレスが設定したFake-IP範囲に含まれることを確認できます。上記の例では、応答が198.18.0.0/16の範囲にあるかを見ます。実在のWebサーバーのIPアドレスが返ってくる場合は、問い合わせが別のDNSサーバーへ送られている、コアの設定が反映されていない、または対象ドメインが除外設定に含まれている可能性があります。

続いて、Clash Verge Revの接続一覧やログで、対象ドメインの接続が表示されるか確認します。ブラウザーでページを開けることだけでは、Fake-IPが使われた証明にはなりません。DNS応答、接続ログに記録されたドメイン、ルールに選ばれたポリシーを合わせて確認すると、名前解決とルーティングのどこで問題が起きているかを切り分けやすくなります。

LANや特定ドメインを除外する

Fake-IPはドメイン名を使ったルール判定に役立ちますが、すべてのドメインに適しているわけではありません。ルーターの管理画面、プリンター、社内システム、NASなど、実際のLANアドレスを返す必要がある名前では、Fake-IP応答がアプリや内部DNSの想定と合わないことがあります。その場合は、該当ドメインをFake-IPの除外対象にするか、内部DNSを使う設定を検討します。

mihomoでは、除外対象をfake-ip-filterに指定する構成が使われます。以下は記述例であり、実際のローカルドメイン名に置き換えてください。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter:
    - '*.lan'
    - 'router.local'

すでにdns:ブロックがある場合は、同じブロック内へ統合してください。除外したドメインは通常のDNS応答を使うため、その名前解決を行う上流DNSがローカルネットワークの名前を知っている必要があります。ローカルネットワーク固有のドメインを、根拠なく広い範囲で除外するのは避けましょう。除外範囲が大きすぎると、ドメインルールでの判定に必要な情報が得られにくくなる場合があります。

設定を変更した後、対象アプリを終了して再起動します。アプリが古いFake-IPをキャッシュしていると、DNS設定を直した後も一時的に接続できないことがあります。WindowsのDNSキャッシュを消去して再確認する場合は、管理者として起動したコマンドプロンプトで次を実行できます。

ipconfig /flushdns

この操作で消去されるのはWindowsのDNSキャッシュです。ブラウザーやアプリが独自に保持するキャッシュは別に残る場合があるため、必要に応じてアプリも再起動してください。

名前解決や接続に失敗したときの見直し方

まず、設定画面でFake-IPが選ばれているか、DNS機能が有効か、変更後の設定が現在のプロファイルへ反映されているかを確認します。次にコアの起動ログを確認し、YAMLの構文エラーやDNSリスナーの起動失敗を探します。問題を切り分ける間は、DNSサーバー、TUN、Fake-IPフィルターを同時に変更せず、一つずつ確認してください。

  • DNS問い合わせがタイムアウトする：listenのアドレスとポート、ファイアウォール、ポート競合を確認します。TUNで取り込む構成なら、TUNが起動しているか、dns-hijackの設定がコアに読み込まれているかも確認してください。
  • 実際のIPアドレスが返る：問い合わせ先がClashのDNSかを確認します。Windowsのネットワーク設定、ブラウザーのセキュアDNS、VPN、別のDNSクライアントが問い合わせを処理していないかを調べます。
  • Fake-IPは返るがページを開けない：接続ログに対象ドメインが表示されるか、ルールの一致先やプロキシグループの選択が適切か、選択中のノードが利用できるかを確認します。名前解決の成功と外部接続の成功は別の段階です。
  • LANの機器だけ接続できない：ローカルドメインのDNS応答、Fake-IP除外設定、LAN向けルール、TUNのルート設定を確認します。端末の実際のローカルIPアドレスへ直接接続できるかも比較します。
  • 再起動後に設定が戻る：リモートプロファイルの更新で変更が上書きされていないか確認します。クライアントの設定管理機能を使い、元のサブスクリプションとローカルオーバーライドを分けて管理してください。

切り分けのため一時的にFake-IPを無効にする場合は、設定を控えてから変更し、確認後に必要な設定へ戻します。クライアントの再インストールは、DNS設定やTUNの経路に原因がある場合、問題の解決につながらないことがあります。ログの時刻、エラーメッセージ、利用中のコアとバージョンを記録してから、設定を見直すのが効率的です。