Clash DNS 設定完全ガイド：Fake-IP・DNS改ざん・自前DNS構築
ルールをどれだけ精密に書いても、ドメインが解決されるIP自体が間違っていれば振り分けは成り立ちません。この記事ではDNS改ざんの仕組み、Clashの2つの解決モードの違い、暗号化DNSとドメイン別解決戦略を掘り下げ、「ルールは合っているはずなのに、なぜか違う経路を通ってしまう」問題を根本から調査できるようにします。
なぜ振り分けの失敗の元凶がDNSになりやすいのか
長時間ルールを調整しても特定のサイトが違う経路を通ってしまう場合、多くの人は最初に「ルールが間違っている」と考えますが、本当の原因はもう一歩手前——DNS解決にあることがよくあります。
ルールベースの振り分けは、まず「このドメイン/IPがプロキシを通るべきかどうか」を知ることが前提であり、その判断には2種類の入力があります。ドメイン自体（DOMAIN、DOMAIN-SUFFIX などのルール）と、解決結果のIP（IP-CIDR、GEOIP などのルール）です。DNS解決の段階で問題が起きると、それ以降のIPベースの判断もすべて連動して誤ります：
- DNS改ざん／ハイジャック：特定のドメインに対して誤った、あるいはアクセス不能なIPを返すネットワークがあります。ブロックまたは制限されているドメインで特によく見られます。
- ISPのDNSが「最寄り」の結果を返す：CDN高速化目的で返されるIPが、実際に接続したいエンドポイントとは異なる場合があり、
GEOIPによる判断に影響することがあります。 - ローカルhosts／キャッシュの汚染：OSやルーターのレベルで誤った結果がキャッシュされているケース。クライアントを再起動しても解決しないのは、問題がClash側にはないためです。
「ルールが効いていない」問題を調査するとき、DNSはルール構文そのものの次に——最後ではなく、最初に確認すべき項目です。
Fake-IP と Redir-Host：2つのモードのトレードオフ
Clash の dns.enhanced-mode は解決動作の根本的なロジックを決定し、2つのモードにはそれぞれトレードオフがあります：
Fake-IP モード
- 各ドメインにローカル限定の偽IPを割り当て、実際の解決は接続が発生するタイミングまで遅延させる
- ルールをドメイン名で直接マッチできるため互換性が最も高く、TUNモードでのデフォルト推奨
- 欠点：「実際のIPを取得して検証する」タイプのプログラム（一部のゲーム、企業VPNクライアントなど）が非対応の場合がある
Redir-Host モード
- 実際の解決結果を直接返すため、従来のネットワークの挙動に近い
IP-CIDR/GEOIPルールの判定精度が上がり、ルーター/ゲートウェイ環境でよく使われる- 欠点：どのプロキシを使うか決めるために実際にDNSクエリを1回発行する必要があり、往復分の遅延が増える
どちらが絶対的に「良い」というものではありません。一般的な目安：デスクトップクライアント＋TUNモードでは fake-ip を優先し、特定のアプリで接続異常が出た場合は、モード全体を切り替えるのではなく fake-ip-filter でそのドメインだけを個別に除外するのがおすすめです。
暗号化DNSで改ざんに対抗する：DoH と DoT
従来のDNSクエリは平文のUDPポート53通信であり、経路上のネットワーク機器が識別・改ざんしやすい状態です。これが「DNS改ざん」の一般的な原因の一つです。解決策はDNSクエリを暗号化チャネルで包むことです：
| 方式 | 正式名称 | 特徴 |
|---|---|---|
DoH | DNS over HTTPS | 通常のHTTPS通信に偽装され、識別されにくい。記法は https://1.1.1.1/dns-query のような形 |
DoT | DNS over TLS | 専用の853ポートで暗号化。DoHよりやや特徴が出やすい。記法は tls://8.8.8.8 のような形 |
| UDP（従来方式） | DNS over UDP | 平文で最速だが経路上に完全に露出する。すでに信頼しているネットワーク——例えばお使いのISP自体のDNS——に使うなら問題ない |
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 9.9.9.9
- 208.67.222.222
fallback:
- https://1.1.1.1/dns-query
- tls://8.8.8.8
fallback-filter:
geoip: true
geoip-code: JP考え方は応用設定ガイドで紹介したものと同じです：普段の解決速度のために nameserver には高速な平文DNSを、正確性のために fallback には暗号化DNSを使い、fallback-filter がいつ fallback に切り替えるかを判断します。geoip-code はお使いの国・地域のコードに設定してください——fallback-filter はこれを使って、自分の地域として不自然な結果を検出し、暗号化DNSに切り替えます。
ドメイン別に解決先を振り分ける：nameserver-policy
「メイン／フォールバック」の粗い分け方では不十分で、特定のドメインだけ専用のDNSサーバーに向けたい場合があります——例えば社内ドメインは社内DNSでしか正しく解決できない、といったケースです。そのために nameserver-policy があります：
dns:
nameserver-policy:
'geosite:private': '9.9.9.9'
'+.internal.company.com': '10.0.0.1'
'+.google.com': 'https://1.1.1.1/dns-query'nameserver-policy はグローバルな nameserver / fallback より優先度が高く、特定ドメインに対する「例外ルール」と考えると分かりやすいです。社内ネットワークや自前で運用しているサービスなど、専用の解決要件があるケースに最適です。
社内ドメインがFake-IPに乗ってしまい、正しい社内DNSに振り分けられていない場合、その社内サービスは「接続はできているように見えるがずっとタイムアウトする」という状態になります。この症状が出た場合は、まず nameserver-policy と fake-ip-filter が社内ドメインを正しく除外しているか確認してください。
解決結果が正しいかどうかを確認する方法
「なんとなく遅い／つながらない」という感覚だけではDNSが原因かどうか判断しにくいものです。より確実な方法は、実際に解決されたアドレスを直接確認することです：
- Dashboard パネル：ほとんどのClashクライアントのパネルで、各接続が実際に使用している宛先IPを確認できます。追加のツールが不要で最も直接的な確認方法です。
- コマンドラインツール：Windowsでは
nslookup ドメイン、macOS/Linuxではdig ドメインまたはnslookup ドメインを使い、Clashを有効化する前と後で同じドメインの解決結果を比較します。 - Fake-IPモード特有の現象：このモードではOSレベルの
nslookupは仮想IP（通常198.18.0.0/16の範囲）を返しますが、これは正常な動作で解決エラーではありません。実際の解決は接続が発生したタイミングでコアが行います。
「DNS改ざんかどうか」を確認する最も簡単な方法：システムDNSまたはClashの nameserver を一時的に暗号化DNS（DoHなど）に切り替えてみます。同じドメインが切り替え後に正常にアクセスできるようになれば、元のDNSが改ざん／ハイジャックされていたと考えられます。
自前でDNSサーバーを構築すべきか
ほとんどの人にとっては、公開されている暗号化DNS（1.1.1.1 や 8.8.8.8 など）だけで改ざん問題は十分解決でき、自前で構築する必要はありません。ただし、複数のデバイスに統一的な解決サービスを提供する必要のある家庭用ゲートウェイやルーターを運用している場合は、自前DNS（AdGuard Home や dnsmasq など）を組み合わせるほうが向いています：
- 広告フィルタリングや振り分け解決をゲートウェイ層で統一的に行えるため、各デバイスで個別に設定する必要がない
- ローカルなホスト名を自由に定義でき（LAN内デバイスに分かりやすい名前を付ける等）、Clashの
nameserver-policyと組み合わせて自前DNSに向けられる - リクエストのログや統計が取れるため、どのデバイス・どのドメインの解決が異常かを調査しやすい
単体のマシンで日常的に使うだけであれば、Clash内蔵のDNSモジュールで nameserver / fallback を設定するだけで十分です。自前DNSはゲートウェイレベルの運用を行う人向けの上級オプションと考えてください。
DNS関連の問題を3ステップで調査する
- Dashboardで問題のある接続の詳細を開き、実際にどのIPに解決されたかを確認します。「解決自体が間違っている」のか「解決は合っているがルールがマッチしていない」のかを判断します。
enhanced-modeを一時的にfake-ipからredir-host（またはその逆）に切り替えて比較テストを行い、問題の範囲を絞り込みます。fallback-filter.geoipが有効になっているか、geoip-codeが自分の地域に正しく設定されているかを確認します。これは最も見落とされやすい細部です。
以上をすべて確認しても特定できない場合は、よくある質問の接続トラブルシューティングチェックリストを参照するか、応用設定ガイドのDNSセクションと照らし合わせて設定全体を見直してみてください。