まず確認：DNSモードとプロキシモードは別

dns.enhanced-mode は、DNSクエリの処理方法と、その後の接続をドメイン名に関連付ける方法を決めます。一方、mode: rule は接続の振り分け方法を決めます。この2つは別の設定です。Fake-IPを選んでもすべての通信がプロキシ経由になるわけではなく、redir-hostを選んでも接続が必ず直接通信になるわけではありません。

この記事では、Clash Meta（現 mihomo）で一般的な設定項目を例に説明します。旧版Clashやクライアントによって対応状況が異なる場合があるため、編集前にクライアントのカーネル情報で使用中のカーネルを確認してください。GUIの設定が設定ファイルを上書きすることもあります。サブスクリプションの原文だけで判断せず、カーネルが実際に読み込んだ設定を確認しましょう。

  • DNS層：ドメイン名の問い合わせを処理し、アプリにアドレスを返します。
  • 通信の入口：システムプロキシ、TUN、またはルーターの透過プロキシで接続をカーネルに渡します。
  • ルール層：rules の順に照合し、直接接続・プロキシグループ・接続拒否のいずれかを選択します。

Fake-IPは通信の取り込みと組み合わせて使う必要があります。アプリが合成アドレスを受け取っても、その接続が対応するマッピングを保持するカーネルに戻らなければ、想定どおりに接続できません。

Fake-IPの仕組み：合成アドレスを返し、ドメイン名を使って接続

アプリが www.example.com を問い合わせるとします。Fake-IPモードでは、カーネルが設定されたアドレスプールから合成IPv4アドレスを割り当て、「合成アドレス → ドメイン名」の対応を保存できます。アプリがそのアドレスへ接続すると、カーネルが接続を受け取り、元のドメイン名を復元して振り分けルールを適用します。

  1. アプリはDNSクエリをClashまたはmihomoのDNSサービスに送ります。
  2. カーネルはアドレスプール内のアドレスを返します。例：198.18.0.2。割り当てられるアドレスは固定ではありません。
  3. アプリがそのアドレスへ接続し、TUNなどの入口を通じて同じカーネルに接続が戻ります。
  4. カーネルがドメイン名を復元してルールを照合し、選択された出口経由で実際の接続を確立します。

よく使われるアドレスが198.18で始まる理由

198.18.0.0/15 はネットワーク機器のベンチマーク用に予約された特殊用途のアドレス範囲で、接続先サイトのグローバルIPアドレスではありません。設定例でよく見かける 198.18.0.1/16 もこの範囲に含まれます。また、一般家庭のLANで使われるRFC 1918のプライベートアドレス範囲とは異なります。企業ネットワークや検証環境で同じ範囲を使用している場合は、ルーティングの競合がないか先に確認してください。

応答が速くても、すべての問い合わせで名前解決が不要になるわけではない

Fake-IPを利用できるクエリでは、通常、カーネルは接続先の実IPアドレスを待たずに合成アドレスをアプリへ返せます。これによりDNS段階の待ち時間を減らし、ドメイン名の情報も保持できます。ただし、直接接続する場合は最終的に実アドレスが必要です。プロキシ経由でリモート側が名前解決するかどうかは、ノードのプロトコルや接続方法によって異なります。初回のページ表示にはハンドシェイクや回線、サーバーの応答も影響するため、一定の速度向上を保証することはできません。

redir-hostの違い：実アドレスを返し、IPアドレスに依存するアプリに対応

redir-hostは上流DNSで実アドレスを問い合わせてアプリに返すと同時に、DNSクエリの記録を使ってドメイン名とアドレスの対応を管理します。接続がカーネルに入ると、これらの対応情報を使ってドメイン名ルールの照合を補助できます。ただし、複数のドメイン名が同じアドレスを共有している場合や、アプリが独自のDNSを使う場合、DNSキャッシュの取得元が異なる場合は、対応関係が不明確になることがあります。

比較項目 Fake-IP redir-host
アプリが受け取るアドレス アドレスプール内の合成アドレス（フィルター対象を除く） 上流DNSで取得した実アドレス
DNS応答の待ち時間 通常、合成アドレスを先に返せる 実際の名前解決結果またはキャッシュが必要
ドメイン名との対応付け 合成アドレスのマッピングからドメイン名を復元 DNS記録などの情報を使って対応付け
よくある互換性の問題 アプリが実IPを確認する、または合成アドレスの通信が取り込まれていない 不適切な名前解決結果、ドメイン名との対応付けが不完全
まず試したい場面 通信が確実に取り込まれている日常のブラウジングやルール振り分け 実際の名前解決結果が必要なツールや互換性の切り分け

redir-hostは「プライバシーモード」ではなく、Fake-IPにしてもすべてのDNS通信が自動的にプロキシ経由になるわけではありません。DoHやDoTを使うか、上流への問い合わせがどの出口を通るか、アプリがシステムDNSを迂回するかは、それぞれ別の問題です。ブラウザーのセキュアDNSを有効にすると、クエリがカーネルのDNSサービスに届かない場合があります。enhanced-mode の値だけを見て、DNSリークの有無を判断しないでください。

Fake-IPの設定：まずDNSの入口を確認し、除外リストを設定

以下は設定項目の関係を説明するためのmihomo DNS設定例です。動作確認済みの既存設定に統合して使ってください。ノードやルールを含む完全な設定ではありません。既存ファイルに dns: がある場合は、その部分を編集し、同じトップレベルキーを重複して追加しないでください。

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:
    - 'localhost'
    - '*.lan'
    - '*.local'
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  • listen：この例ではローカルのループバックアドレスの 1053 ポートだけで問い合わせを受け付けます。システムDNSは自動変更されず、LAN内の機器から接続できるようにもなりません。
  • enhanced-mode：この拡張モードを有効にするには fake-ip を指定します。
  • fake-ip-range：合成アドレスのプールを指定します。プロキシノードのアドレスやDNS上流サーバーのアドレスではありません。
  • fake-ip-filter：この例ではデフォルトのブラックリスト方式を使い、一致した項目には実際の名前解決結果を返します。
  • nameserver：ここでは説明用に通常のDNS上流サーバーを2つ指定しています。実際にはネットワークからの到達性とプライバシー要件に合わせて変更してください。

一部の新しいmihomoでは、fake-ip-filter-mode でフィルター方式を変更できます。既存設定で whitelist を明示している場合、リストの意味が逆になるため、この記事の除外リストをそのまま適用できません。別のカーネルへ移行する際は、まず設定項目の対応状況を確認してください。

fake-ip-filter はDNSが合成アドレスを返すかどうかを決める設定であり、DIRECT ルールを追加するものではありません。直接接続する必要がある接続先には、rules で適切な振り分けルールも設定してください。

TUNのDNSハイジャックとリスニングポートは別々に考える

該当項目に対応するmihomo設定では、tun.dns-hijack を使って通常のDNS通信をカーネルに渡せます。以下の例はUDPとTCPの 53 番ポートへの問い合わせを取り込む設定です。アプリ独自のDoHを直接復号できるという意味ではありません。TUNの有効化に必要な権限、ルート、クライアントによる設定上書きは別途確認してください。

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

この設定をシステムプロキシと同じ入口として扱わないでください。ブラウザーがHTTPプロキシを使う場合、ドメイン名を直接プロキシに渡し、ローカルDNSを使わないことがあります。一方、TUNではアプリによる名前解決からIPアドレスへの接続まで、経路全体を取り込む必要があるケースがよくあります。

ゲーム・LAN機器でのfake-ip-filterの使いどころと注意点

LAN内のNAS・プリンター：まずローカルの名前解決を確認

ルーターが通常のDNSで nas.home.arpa を提供している場合、この名前を除外し、そのレコードを把握しているルーターのDNSへ問い合わせを送る方法があります。ルーターのアドレスが 192.168.1.1 であることを確認したうえで、既存のDNS設定に次の項目を追加してください。

  fake-ip-filter:
    - 'localhost'
    - '*.lan'
    - '*.local'
    - 'nas.home.arpa'
  nameserver-policy:
    'nas.home.arpa':
      - 192.168.1.1

ルーターのアドレスは現在のネットワークに合わせてください。フィルターリストを設定しても、ローカルDNSレコードが自動的に作られるわけではありません。192.168.1.20 に直接アクセスしてNASを使う場合は、ドメイン名の問い合わせが発生しないため、Fake-IPのフィルターを変更しても通常は効果がありません。プライベートネットワークのルート、TUNの除外設定、ファイアウォールを確認してください。

.local はmDNSによる機器検出にもよく使われます。*.local をフィルターリストに入れても、mDNSのマルチキャストが自動転送されるわけではなく、異なるネットワークセグメント間のプリンター検出も解決しません。「機器が見つからない」問題と「既知のアドレスに接続できない」問題を分けて調べてください。

ゲーム・音声通話：カテゴリ全体ではなく問題のあるドメインだけを除外

ゲームや音声通話、一部の疎通確認ツールでは、DNSが返すアドレスを確認したり、解決結果を別の機器で使ったりすることがあります。このような処理は合成アドレスと相性が悪い場合があります。まずログから、ログイン・マッチング・音声通話・STUNに関係する実際の問い合わせ先を特定し、正確なドメイン名だけをフィルターリストに追加してください。サービス名だけを頼りに大量のドメインを推測して追加しないでください。

  • ログインできるのに音声通話が使えない：ノードのUDP対応状況、UDPの振り分け、NATの条件も確認してください。DNSフィルターでUDP対応を補うことはできません。
  • 特定の検査だけ失敗する：まず、その検査に使われるドメインだけを除外し、ほかの通信ではFake-IPを引き続き使います。
  • スマートフォンからPCのプロキシを共有して使う：スマートフォンが合成アドレスに接続するときも、そのマッピングを生成したPCのカーネルを経由することを確認してください。DNSの参照先をPCにするだけでは不十分です。

「すべての互換性問題を解決する」ために '*' を追加するのはおすすめしません。ブラックリスト方式では、これによって一致するすべての問い合わせがFake-IPを使わなくなり、アドレスマッピングの仕組みが失われます。また、どの項目が問題の原因だったのか特定しにくくなります。

モード切り替え後の確認手順とよくある誤解

  1. 設定をバックアップし、変更は1項目ずつ。現在の設定を保存してから、DNSモードまたはフィルター項目を1つだけ変更します。ノード、ルール、TUNのルートを同時に変更しないでください。
  2. 設定を再読み込み。YAMLのインデント、未対応の項目、ポート競合に関するエラーがログにないか確認してください。読み込みに失敗した場合、カーネルが以前の設定を使い続けていることがあります。
  3. DNS応答を確認。この記事のリスニングアドレスに対して、次のコマンドを実行し、問い合わせがカーネルに届いていることを確認します。
  4. 古い名前解決情報をクリア。対象アプリを終了して再起動し、必要に応じてシステムのDNSキャッシュも消去します。既存の接続やアプリ独自のキャッシュは、設定ファイルを編集しただけでは消えません。
  5. 実際の接続を確認。クライアントの接続ログで対象ドメイン、適用されたルール、出口を確認し、問題が名前解決・振り分け・接続のどの段階で起きているか判断します。
dig @127.0.0.1 -p 1053 www.example.com A

# Windows PowerShell：システムのDNSキャッシュをクリア
Clear-DnsClientCache

# Windows コマンドプロンプト：同様の操作
ipconfig /flushdns

dig を使うには、対応するツールがシステムにインストールされている必要があります。このコマンドでは 1053 ポートを明示的に指定しています。通常の nslookup を実行しても、システムに設定されたDNSがテストされるとは限らず、この記事のリスニングサービスに問い合わせるとは限りません。フィルター対象外のドメインについては、Fake-IPモードでアドレスプール内のAレコードが返るのが正常です。これを、公開DNSの応答が改ざんされた証拠と見なさないでください。

redir-hostに切り替えても198.18のアドレスに接続される理由

よくある原因は、アプリが古いアドレスを保持しているか、クライアントが新しい設定をカーネルに適用していないことです。まず実際に動作しているモードを確認し、古い接続を終了してキャッシュを消去してから再試行してください。カーネルの再起動でFake-IPのマッピングが失われても、アプリが古い合成アドレスを保持していると接続に失敗することがあります。対応カーネルでは profile.store-fake-ip でマッピングを永続化できますが、通信を正しく取り込む設定の代わりにはなりません。

IPアドレスを使うルールは引き続き有効か

Fake-IPにしてもIPアドレスルールが無効になるわけではありません。カーネルは必要に応じて接続先の実アドレスを解決し、ルール照合に使います。動作はルールの順序、キャッシュ、no-resolve などのパラメーターにも左右されます。合成アドレスから接続先の地域を判断しないでください。また、サイトへの接続を直すためにFake-IPのアドレスプール全体へ直接接続ルールを設定するのも避けてください。

選び方：普段は安定性を優先し、互換性の問題は個別に対処

日常的なWeb閲覧で通信の入口が明確で、DNSがカーネルに届く環境なら、まずFake-IPを試せます。NAS、ゲームのログイン、特定の検査だけに問題がある場合は、根拠のある項目だけをフィルターに追加し、ローカルDNSとルールも適切に設定してください。アプリが実アドレスを必要とする場合や、合成アドレスの通信を環境全体で取り込むのが難しい場合に、redir-hostとの比較を試しましょう。

判断基準はDNSクエリ単体の所要時間ではなく、名前解決、ルール照合、接続確立、データ転送まで、対象アプリの一連の処理が安定して完了するかどうかです。動作する設定を保存し、変更した項目と再現手順を記録しておくと、複数の設定を一度に切り替えるより問題を特定しやすくなります。初期設定についてはサブスクリプションの追加と設定ガイドを、接続に問題がある場合はトラブルシューティングガイドをご覧ください。