まずDNSと通信がコアを経由しているか確認
Fake-IPを設定する前に、2点を確認しましょう。アプリのDNS問い合わせがClashのコアに届くこと、そしてアプリが続けて行う接続も同じコアで処理されることです。DNSだけを有効にして接続が物理ネットワークへ直接流れると、アプリがインターネット上では到達できない合成アドレスを受け取り、ページの読み込みが終わらないことがあります。
- クライアントの設定詳細または実行中の設定で、
dns.enableがtrue、dns.enhanced-modeがfake-ipになっていることを確認します。 - 現在の接続方式がシステムプロキシかTUNかを確認してください。システムプロキシが対象にするのはプロキシ設定に従うアプリだけです。TUNはより多くのIP通信を処理できますが、ルーティングとDNSの設定が正しい必要があります。
- クライアントの接続パネルを開き、新しいドメインにアクセスして、ドメイン名、適用ルール、出口が表示されるか確認します。メニュー名はクライアントによって異なるため、ホーム画面の「接続済み」表示だけで判断しないでください。
- Clash Meta（現名称：mihomo）を使っている場合は、現在のコアで有効な設定を確認してください。クライアントのエディターに表示されるサブスクリプションの原文が、マージやオーバーライド後の実行設定と一致するとは限りません。
DNSマッピングがルールによる振り分けにつながる仕組み
実IPの応答からローカルマッピングへ
従来の流れでは、アプリはまずDNSで接続先の実IPを取得し、そのIPに接続します。Fake-IPでは、アドレスプールから 198.18.0.2 のような合成IPv4アドレスを割り当て、コア内に「ドメイン ↔ 合成アドレス」の対応関係を保存します。このアドレスは流れを説明するための例で、問い合わせのたびに同じ値が返るわけではありません。
- アプリが
www.example.comのAレコードを問い合わせます。 - コアはドメインとFake-IPの対応を記録し、合成アドレスをアプリに返します。
- アプリがそのアドレスに接続すると、システムプロキシやTUNなどの経路を通じてコアに渡されます。
- コアは接続先アドレスからドメインを特定し、ドメインルールに基づいてプロキシグループを選択します。その後、選択した出口を使って接続します。
よく使われる設定の 198.18.0.1/16 は、ベンチマーク用に予約された 198.18.0.0/15 アドレスブロック内の範囲であり、接続先サイトのグローバルIPではありません。「無料ノードのアドレス」でもありません。社内ネットワークや検証環境、別のVPNで重複するネットワーク範囲を使っている場合は、先にルートの競合を解消してください。
待ち時間を短縮できる理由
ドメインルールで判定でき、プロキシプロトコルがドメイン名の転送に対応している接続では、接続先の実DNS応答を待たずにプロキシ接続を開始できます。実際の名前解決をリモート側に任せられるため、ローカルDNSの問い合わせが接続処理のボトルネックになる機会を減らせます。
すべての接続が速くなるわけではありません。直接接続する場合は通常、実IPが必要です。IPベースのルールに一致したときも、名前解決が発生する場合があります。ノードとの往復遅延、リモートDNS、ハンドシェイク、接続先サイトの応答が主な遅延要因になることもあります。Fake-IPで利用できないノードが使えるようになるわけではなく、ノードの遅延測定値が自動的に下がることもありません。
Fake-IPとredir-hostの違い
| 比較項目 | fake-ip | redir-host |
|---|---|---|
| Aレコードの応答 | 除外されていないドメインには、通常、合成アドレスを返します。 | 上流DNSで解決した実アドレスを返します。 |
| ドメインとの関連付け | Fake-IPのマッピングから接続先ドメインを特定します。 | DNSキャッシュなどの情報からドメインを関連付けられますが、実IPを複数のドメインで共有している場合があります。 |
| ローカルでの名前解決待ち | 一部のプロキシ接続では、ローカルでの実IP解決を後回しにしたり、省略したりできます。 | 通常、DNS応答の前に実IPの解決が必要です。 |
| よくある互換性の問題 | アプリによる実IPの確認、マッピングの消失、接続がコアに取り込まれていない。 | ローカルDNSの品質、共有IPからのドメイン特定、ルールによる振り分けの判定。 |
| 選択の目安 | ドメインルールによる振り分けが中心で、DNSと通信経路を管理できる場合。 | アプリが実DNS応答に依存している場合や、互換性を優先する場合。 |
redir-hostはドメインルールを無効にする方式ではなく、Fake-IPも上流DNSへの問い合わせを完全になくす方式ではありません。接続メタデータ、DNSキャッシュ、スニッフィング設定、ルールの順序によって、実際の動作は変わります。トラブル時は接続パネルで実際のドメインと適用ルールを確認し、モード名だけで推測しないでください。
特定のゲームやNASだけで問題が起きる場合は、すぐに全通信をredir-hostへ切り替えるのではなく、まず関連ドメインを個別に除外してください。多くのアプリが実アドレスに依存しており、適切な例外設定を維持できない場合は、全体の切り替えを検討し、同じネットワーク・同じ出口で結果を比較します。
fake-ip-filterの設定と注意点
従来のClashとmihomoのブラックリスト方式では、fake-ip-filter に登録したドメインにはFake-IPを割り当てず、実IPを解決します。「ホワイトリスト」と呼ばれることもありますが、正確には「Fake-IPの除外リスト」です。プロキシの許可リストではなく、直接接続するかどうかも決まりません。
以下は動作確認用のDNS設定例で、サブスクリプション全体ではありません。例では、システムで一般的に使われる 53 番ポートを直接使わないよう、ローカルの 1053 番ポートを指定しています。2つのパブリック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'
- '+.home.arpa'
nameserver:
- 1.1.1.1
- 9.9.9.9listenは待ち受けアドレスを指定するだけです。この設定だけでシステムDNSが自動的に1053番ポートを使うようにはなりません。クライアントまたはシステム側で転送や通信の取り込みを設定する必要があります。ipv6: falseは、この例のAAAA応答の流れを簡略化するための設定です。すべてのネットワークでIPv6を無効にする指示ではなく、OSのIPv6が無効になるわけでもありません。'*.lan'は、このパターンに一致するLAN内のサブドメインを対象にします。対応するドメインマッチ構文では、'+.'形式でドメイン自体とサブドメインの両方を対象にできます。シングルクォートで囲むと、ワイルドカードがYAMLに誤って解釈されるのを防げます。- mihomoには
fake-ip-filter-modeなどの拡張機能もあります。実行設定がwhitelistの場合は、リストの意味が反転します。使用前にコアの対応状況と現在のモードを確認し、異なるモード向けの設定例を混在させないでください。
サブスクリプションの更新で元のファイルが置き換わることがあります。設定を長期的に維持するには、クライアントが対応するオーバーライドまたはマージ設定に記述し、最終的な実行設定を確認してください。特にリストのマージ方式に注意が必要です。クライアントによっては項目を追加せず、フィルターリスト全体を置き換えます。
除外リストに追加するドメインの選び方
LAN内サービスと内部ドメイン
NAS、プリンターの管理画面、社内システムは、まず確認したい対象です。たとえば、内部DNSが nas.home.arpa を 192.168.1.20 に解決し、アプリがこのプライベートアドレスを認識する必要がある場合は、その名前を除外し、内部DNSで解決させます。適切なLANルールと通信経路がすでに設定されていれば、除外は不要なこともあります。実際の症状を基準に判断してください。
.local はmDNSで使われることがあります。mDNSは通常のユニキャストDNSとは異なるマルチキャスト探索を使うため、フィルターリストに追加しても、セグメント間の探索、マルチキャストルーティング、ファイアウォールの問題は自動では解決しません。IPアドレスで機器のページを開けるのに機器一覧に表示されない場合は、マルチキャストとインターフェースの選択も確認してください。
アドレスの結果を厳密に確認するアプリ
一部のゲーム、デバイスのペアリングツール、ネットワーク診断ソフトは、DNSの結果をアドレス検証、地域判定、後続のプロトコル交渉に使います。ログや比較テストでFake-IPが原因と確認できた場合に限り、該当アプリが実際に問い合わせているドメインを除外してください。ドメインを1つずつ追加し、アプリを再起動して再テストするほうが、出所不明のリストを何百件もコピーするより原因を特定しやすくなります。
- 日本国内のサイトだからといって、すべてのドメインを除外しないでください。直接接続かプロキシ経由かはルールで決まり、Fake-IPのアドレスでは決まりません。
- 修復策として、トップレベルドメイン全体を除外リストに入れないでください。対象範囲が広すぎると、多数の問い合わせで名前解決の経路が変わります。
- ノードのサーバー名が解決できない問題を、すべてFake-IPのせいにしないでください。mihomoでは、ノードのドメイン解決に
proxy-server-nameserverなど別の設定が関係することもあります。 - フィルターは通常ドメインを指定します。
192.168.1.20のような接続先IPを登録しても、LAN内へのアクセスがすべて直るわけではありません。
DNS応答と接続結果を確認する
設定をバックアップしてから変更を適用してください。以下のコマンドで例の待ち受けポートへ直接問い合わせると、「コアが正しく応答するか」と「システムが実際にコアを使っているか」を分けて確認できます。macOSまたはLinuxに dig がインストールされている場合は、次のコマンドを実行します。
dig @127.0.0.1 -p 1053 www.example.com A +short
dig @127.0.0.1 -p 1053 nas.home.arpa A +short1つ目の問い合わせは、この例の設定では通常 198.18.0.0/16 の範囲内のアドレスを返します。具体的なアドレスは固定されません。2つ目は内部DNSが正しく接続されていれば、内部サービスの実アドレスを返します。パブリックDNSから応答がない、またはドメインが存在しないという結果だけでは、フィルターが機能していないとは判断できません。
- 応答を確認。タイムアウトする場合は、コアが
127.0.0.1:1053で待ち受けているか、設定が正しく読み込まれたかを確認します。実際のグローバルIPが返る場合は、フィルタールールと現在の拡張モードを確認してください。 - アプリの通信経路を確認。ブラウザーで同じドメインにアクセスし、接続パネルを確認します。直接問い合わせが成功しても、テストコマンドがコアに届いたことしか分からず、ブラウザーが同じDNS経路を使っているとは限りません。
- ルールと出口を確認。想定したドメインルールとプロキシグループが適用されているか確認します。ドメインが表示されるのに接続できない場合は、ノード、接続先ポート、リモートでの名前解決を引き続き確認してください。
- 変更前後を記録。DNS応答、接続ログ、アプリの結果を変更前後で記録し、フィルターリスト、モード、DNSサーバーのうち一度に変更するのは1項目だけにします。
pingで合成アドレスを確認して、ノードの利用可否を判断しないでください。ICMPとブラウザーが使うTCPやQUICは異なる通信です。また、TUNでのICMP処理も異なる場合があります。実際に使う通信が完了するかどうかを優先して確認してください。
よくあるトラブルの確認手順
モードを切り替えても一部のサイトが開けない
まずキャッシュを消去します。Windowsでは ipconfig /flushdns を実行してシステムのDNSキャッシュを消去し、関連アプリを完全に終了してから再起動します。ブラウザー、ランタイム、アプリが個別のキャッシュを保持していることがあり、システムキャッシュを消去しても古いアドレスがすべて消えるとは限りません。コアの再起動でマッピングが変わり、アプリが古いFake-IPを使い続けて接続に失敗することもあります。
TUNを有効にしてもDNSがコアを経由しない
対応するmihomo設定では、TUNの dns-hijack に any:53 を指定するのが一般的です。ただし、動作するかどうかはプラットフォーム、ルーティング、権限によって異なります。この設定が扱うのは主に従来のDNS通信であり、ブラウザーがHTTPS経由で行うDoH問い合わせを復号することはできません。切り分ける際はブラウザーのセキュアDNSを一時的に無効にし、応答と接続ログを比較してから、DNSを統一する方法を検討してください。
ルールにDIRECTを指定してもLAN機器に接続できない
DIRECTが決めるのは通信の出口です。内部DNSレコードが自動で用意されるわけではなく、別のVPNとのネットワーク範囲の競合も解消されません。内部ドメインが正しいアドレスに解決されるか、そのアドレスへのシステムルートが正しいか、TUNが取り込むべきでないネットワークまで処理していないか、機器のポートに到達できるかを順に確認してください。
どちらのモードを使うか決めるには
通常のWeb閲覧やドメインルールによる振り分けには、まずFake-IPを試せます。一部の互換性の問題は、該当ドメインだけを正確に除外して対処します。実DNSの結果に依存するアプリが多い場合は、redir-hostと比較テストしてください。判断基準は、実際の通信、ルールの適用、名前解決の経路がすべて想定どおりであることです。DNS応答がグローバルIPらしく見えるかどうかではありません。通信の取り込みやルールの基本については、ルールによる振り分けガイドとポート設定の説明をご覧ください。