Clash Fake-IPモード解説｜DNSの仕組みと設定・使いどころ

Fake-IPの仕組み：マッピング用アドレスを返し、ドメイン名をもとに接続を処理

Fake-IPを有効にした状態でWebサイトのドメインを検索すると、198.18.x.xが返ることがあります。これは通常の動作で、Webサイトの実際のアドレスが変わったわけではありません。ClashのDNSモジュールは指定されたアドレスプールから合成IPv4アドレスを割り当て、内部にドメイン名との対応関係を保存します。アプリがそのアドレス宛てに接続すると、コアが通信を受け取り、対応関係から元のドメイン名を復元します。

処理の流れは大きく4段階に分けられます。enhanced-mode: fake-ipと設定するだけでなく、この流れを把握しておくとトラブルの原因を特定しやすくなります。

1. アプリがwww.example.comのAレコードを問い合わせると、リクエストはコアのDNSサービスに届きます。
2. DNSモジュールはアドレスプールから198.18.0.2などのアドレスを割り当て、対応するドメイン名を記録します。割り当てられるアドレスは固定ではありません。
3. アプリは合成アドレスのTCP 443ポートに接続します。通信はTUNなどの透過的な通信制御を通じてコアに届きます。
4. コアがドメイン名を復元し、ルールに基づいて接続先を選択します。その後、DIRECTまたはプロキシの各接続先が必要に応じて実際のアドレスを解決し、接続します。

Fake-IPでは、接続確立時にドメイン名をルール判定へ渡せるため、一部の環境でローカルの実アドレス解決への依存を減らせます。ただし、すべての接続で実DNSが不要になるわけではありません。DIRECT接続先、IP情報を必要とするルール、プロキシノード自体のドメイン名では、引き続きDNS問い合わせが発生する場合があります。また、Fake-IPは暗号化プロトコルではなく、平文DNSを自動的に暗号化DNSへ変換するものでもありません。

Fake-IPとredir-hostの違い：DNS応答とドメイン名の復元方法

redir-hostは上流DNSが解決した実アドレスを返し、fake-ipは対象となる問い合わせに合成アドレスを返します。どちらもルールによる通信の振り分けに使えますが、アプリに返されるアドレスと、コアがドメイン名を特定する方法が異なります。

どちらのモードが常に速い、という固定的な順位はありません。初回の名前解決にかかる時間、プロキシノード側のDNS環境、ルールによるIP問い合わせの有無などで接続時間は変わります。比較する場合は、同じネットワーク・同じノード・同じWebサイトで繰り返しテストしてください。一度のページ読み込みだけで優劣を判断するのは避けましょう。

mihomoのDNS設定：最小構成と動作条件

以下はmihomoで使えるDNS設定例です。ノードやルールを含む完全な設定ではありません。動作を個別に確認できるよう、DNSの待ち受け先をローカルの127.0.0.1:1053にしています。通常、OSのDNS設定で指定できるのはDNSサーバーのアドレスで、ポートは53が使われます。1053番ポートをそのままシステム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
    - 1.1.1.1

• enableで内蔵DNSを有効にします。DNSを有効にせずモードだけ設定しても、想定したマッピング応答は得られません。
• listenで待ち受けアドレスとポートを指定します。ループバックアドレスへの接続はローカル端末からのみ可能で、LAN全体にサービスを提供するものではありません。
• ipv6: falseは、この設定例でAAAA問い合わせの処理を簡略化するための指定です。OSのIPv6対応ネットワークアダプターやルーティングを無効にする設定ではありません。
• fake-ip-rangeで合成IPv4アドレスの範囲を指定します。既存のVPN、検証用ネットワーク、ルーティング設計と照らし合わせ、アドレス範囲が重複しないようにしてください。
• nameserverは実際の名前解決が必要な場合に問い合わせる上流DNSを指定します。例のIPアドレスは通常のDNSを使用しており、上流DNSに現在のネットワークから到達できる必要があります。暗号化DNSを使う場合は別途設定してください。

設定を有効にする前に確認する3つのポイント

1. 実際に動作しているコアを確認します。クライアントのコア情報と起動ログを確認してください。Clash、Clash Meta、mihomoでは対応する設定項目が完全には一致しません。新しいコア向けの追加項目を古いバージョンにそのまま適用しないでください。
2. 編集している設定が実際に適用されるか確認します。サブスクリプションの設定ファイルは更新時に上書きされることがあります。クライアントのオーバーライドまたはマージ機能を使い、再読み込み後に最終的な設定を確認してください。
3. DNS問い合わせと接続の両方がコアに届くか確認します。1053番ポートへの問い合わせが成功しても、DNSサービスが使えることしか確認できません。アプリから合成アドレスへの接続をコアに届けるには、TUNなどの透過転送機能も必要です。

fake-ip-filter：実アドレスが必要なドメインだけを除外

mihomoのデフォルトのブラックリスト方式では、fake-ip-filterに一致したドメインにはFake-IPを返さず、実アドレスを解決します。これはプロキシルールの一覧ではなく、DIRECTや特定のプロキシグループを選択する設定でもありません。最終的な接続先は、出力ルールやその他のルーティング設定で決まります。

前述の例では、よく使われるLAN内のドメインサフィックスを*.lanと*.localで指定しています。ドメインのマッチ方法や特殊ルールの対応状況は、実際に使うコアのドキュメントで確認してください。設定でfake-ip-filter-modeを別途指定している場合は、その動作を確認してからフィルター一覧の効果を判断しましょう。

実際に問題があるドメインだけを追加し、長いリストをまとめてコピーしない

• 企業内ネットワークのドメイン：たとえば、社内サービスのアドレスとして10.20.0.15を返す必要がある場合は、まず対象の完全なドメイン名を除外します。除外後の問い合わせが企業内DNSに届くようにしないと、存在しないアドレスや誤った結果が返る可能性があります。
• 接続先アドレスを検証するアプリ：リモート接続ツール、デバイス検出機能、ゲームの一部はDNS応答を検証します。まず問題のあるドメインだけを対象にテストし、その後にマッチ範囲を広げるか判断してください。
• LAN内デバイスの名前解決：プリンター、NAS、画面共有デバイスなどはローカルドメインを使うことがあります。ただし、デバイスの検出にはmDNSマルチキャスト、ブロードキャスト、その他のプロトコルが使われる場合もあります。ドメインの除外で解決できるのは、DNS応答に関する問題だけです。

nas.home.arpaだけで問題が起きる場合は、サフィックス全体を除外するよりも、まずこの完全な名前を追加して検証しましょう。除外範囲を広げるほど実アドレスの名前解決に戻る通信が増えるため、LAN内DNSや通信振り分けの適切な管理が必要になります。NTPも一律に除外する必要はありません。機器やアプリで再現性のある互換性問題が発生した場合に限り、実際に問い合わせている時刻サーバーのドメイン名を対象にしてください。

確認方法：DNS応答・接続・ルールをそれぞれ確認

検証では、ブラウザーでWebサイトを開けるかどうかだけを見ないでください。ブラウザーが独自のセキュアDNSを使っていたり、アドレスをキャッシュしていたりする可能性があります。サイトが開けても、Fake-IPの経路を通っているとは限りません。まずローカル端末からDNSサーバーを明示して問い合わせ、その後にアプリの接続を確認しましょう。

手順1：コアにAレコードを明示的に問い合わせる

# macOS / Linux：digのインストールが必要
dig @127.0.0.1 -p 1053 www.example.com A

# AAAAレコードも確認し、設定例のIPv6指定を検証
dig @127.0.0.1 -p 1053 www.example.com AAAA

Aレコードが設定した198.18.0.0/16のアドレス範囲に含まれていれば、その問い合わせでマッピング用アドレスが返されています。常に198.18.0.2が返るとは限らないため、その値を期待しないでください。また、返されたアドレスをhostsファイルに手動で登録しないでください。フィルターに一致するドメインは別途確認し、アドレスプール内の値ではなく、上流DNSが返す実アドレスまたは該当するDNS応答を確認します。

手順2：古いキャッシュを消去して同じ接続先をテスト

# Windows：ターミナルで実行
ipconfig /flushdns

# systemd-resolvedを使用しているLinux
sudo resolvectl flush-caches

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

これらのコマンドで消去されるのはシステム側のキャッシュです。ブラウザー、アプリ、コアのキャッシュも同時に消えるとは限りません。テスト対象のアプリを終了して再起動し、必要に応じてクライアントからDNSキャッシュを消去したうえで、新しい接続を試してください。コアを再起動すると、以前の合成アドレスとマッピングが引き継がれない場合があります。そのため、ブラウザーで古い接続を再利用すると、一時的に失敗することがあります。

手順3：接続ログでドメイン名と出力先を確認

クライアントの接続一覧またはログで、対象のドメイン名、適用されたルール、出力先が想定どおりか確認してください。より詳しい情報が必要な場合は、一時的にlog-levelをdebugに変更し、テスト後に通常のレベルへ戻します。ログを共有する前に、サブスクリプションURL、アクセストークン、ノードの認証情報、機密性の高いドメイン名を削除してください。

よくあるトラブル：通信経路に沿って原因を確認

実アドレスの解決にも失敗する場合は、上流DNSに接続できるかを先に確認してください。fake-ip-filterの範囲をむやみに広げるのは避けましょう。DNSが正常で、接続ログにも正しいドメイン名が表示されているのにプロキシ接続がタイムアウトする場合は、ノードへの接続性と出力ルールを確認してください。Fake-IPが処理するのは通信経路の前半であり、使えないノードや誤ったプロキシ認証情報は解決できません。

ブラウザーのセキュアDNS、AndroidのプライベートDNS、アプリ内蔵のDoHを使っている場合、問い合わせがコアの通常のDNS入口を迂回することがあります。53番ポートのリダイレクトだけでは、HTTPS内のDNS問い合わせすべてを処理できません。テストではまず名前解決の経路を統一し、その後、どのDNS方式を使い続けるか判断してください。複数の設定を同時に変更しないようにしましょう。

用途と元に戻す手順

TUNが安定して動作し、ドメイン名による通信振り分けが必要なデスクトップ環境では、Fake-IPを優先して試す価値があります。一方、企業VPNや複雑なLAN、アプリに接続先の実IPアドレスを表示する必要があるツールでは、ルーティングと名前解決の要件を先に確認し、必要に応じてredir-hostを使ってください。AndroidではVPNインターフェースを複数のVPNアプリで共有できないことが多く、DNSモードを切り替えるだけでは競合を解消できません。

1. まず問題箇所だけを修正：特定のドメインだけに問題がある場合は、再現手順を記録し、対象を正確にフィルターへ追加して実アドレスの名前解決を確認します。
2. 次に通信制御の範囲を確認：合成アドレスへの接続が広範囲でタイムアウトする場合は、フィルター項目を追加するのではなく、ルーティング、DNSの通信制御、権限の問題を優先して解決します。
3. 最後にモードの変更を検討：アプリが実アドレスを必要としている場合、または現在のネットワークで合成アドレスを安定して制御できない場合に、enhanced-mode: redir-hostを試してください。

切り替える前に、元に戻せる設定を保存します。切り替え後は設定を再読み込みし、キャッシュを消去してください。最終的には、DNS応答がモードに合っていること、接続に正しいルールが適用されていること、普段使うアプリとLAN内サービスが安定して動作することの3点で判断します。出どころが分からないフィルター項目を増やし続けるより、内容を把握できる最小限の設定を維持するほうが管理しやすくなります。