Clash DNS 設定の完全ガイド:nameserver・fallback・DNS ハイジャックの正しい書き方

Clash の dns セクションは、設定の中でも特に解釈が分かれやすい部分です。同じ設定でも、ある人はページが一瞬で開き、別の人はいつまでも読み込み中のまま。その差を生むのはノードではなく、nameserver・fallback・dns-hijack の 3 つのフィールドの連携です。この記事では dns セクションの記述順に沿って、各フィールドがなぜ存在し、いつ有効になるのかを解説します。

まず dns セクションを正しく設定する:enable・listen・enhanced-mode

dns セクションは単なるスイッチの集まりではなく、Clash 内蔵 DNS サーバーの完全な設定です。その役割は 3 つあります。クエリを受け取ること、返すアドレスを決めること、結果をルーティングルールに渡すことです。まず最小構成を見てみましょう:

dns:
  enable: true
  listen: 127.0.0.1:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enable は内蔵 DNS を動作させるかどうかを決めます。オフの場合、システムプロキシモードではすべてのドメインがシステムのリゾルバーに渡され、ルール内の GEOIP や IP-CIDR の判定には汚染されたアドレスが渡される可能性があり、分流が正確に機能しません。オンにすると、Clash 自身がリゾルバーとなり、クエリ結果がルールマッチングにも使われます。

listen は待受アドレスとポートを決めます。127.0.0.1:53 はローカルマシンのみにサービスを提供し、純粋なシステムプロキシ環境に適しています。0.0.0.0:53 は LAN 内のデバイスと TUN 経由でハイジャックされたクエリの両方にサービスを提供するため、TUN モードではこちらを推奨します。53 番ポートが他のプログラムに使用されている場合は 127.0.0.1:5353 に変更できますが、システム DNS とプロキシ設定も合わせて変更する必要があります。

enhanced-mode は 2 択です。fake-ip は予約レンジのダミーアドレスを返し、redir-host は実際のアドレスを返します。このフィールドはルールマッチングに最も影響するため、第 4 節で詳しく説明します。先に結論だけ:TUN モードでは fake-ip を選びます。

nameserver と fallback の役割分担:メイン経路と予備経路

nameserver はメインの解決経路です。各ドメインはデフォルトでまずここに渡されます。fallback は予備の解決経路で、nameserver の結果が信頼できないと判定された場合にのみ 2 回目の解決が行われ、fallback の結果が優先されます。

判定ロジックを一言で言うと:nameserver が返した IP が中国本土のものであれば、ドメインは汚染されていないと判断してそのまま使用します。海外のアドレスを返した場合は汚染の疑いがあるため、fallback で再解決します。したがって 2 つのリストには明確な役割分担があります。nameserver には中国国内の DNS を置いて速度を優先し、fallback には海外の信頼できる DNS を置いて正確性を優先します。

  nameserver:
    - 223.5.5.5
    - 119.29.29.29

  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

• nameserver には通常の UDP クエリを使う中国国内 DNS を推奨します。遅延は数ミリ秒で、中国国内の CDN ドメインには最寄りのノードを返します。
• fallback には DoH を推奨します。結果が信頼でき、汚染にも強いからです。1.1.1.1 と 8.8.8.8 は IP 直書きなので、追加の名前解決に依存しません。
• 逆にしてはいけません。nameserver に海外、fallback に中国国内を入れると、すべてのクエリが遅い海外解決を通り、本当に修正が必要なときに fallback が返すのは中国国内の結果のままとなり、仕組みが意味を失います。
• fallback リストにも中国国内 DNS を混ぜないでください。汚染されたドメインが依然として誤った IP を取得してしまいます。

fallback-filter のフィルタリングロジック:geoip・ipcidr・domain

fallback-filter は fallback をいつトリガーするかを決めます。nameserver の解決結果だけを見て、次の 3 つの条件で構成されています:

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - 127.0.0.0/8
    domain:
      - '+.google.com'
      - '+.youtube.com'

geoip と geoip-code がメインスイッチです。geoip: true は nameserver が返した IP の地理位置を判定することを意味し、geoip-code: CN は「中国本土の IP は信頼できる」と見なすことを意味します。この条件に該当すれば、nameserver の結果をそのまま使用します。

ipcidr は信頼できる IP レンジを追加します。ローカルネットワークのドメインが解決するプライベートアドレスには国がなく、geoip によって海外の結果と誤判定されて fallback が繰り返しトリガーされるため、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8 を列挙します。240.0.0.0/4 は元の Clash ドキュメントの例にある予約レンジなので、残しておいて問題ありません。

domain は例外リストです。ここに書かれたドメインはフィルタリングを経ず、直接 fallback に渡されます。構文上、+.google.com はメインドメインとすべてのサブドメインを意味し、*.google.com はサブドメインのみを意味します。よく使う海外ドメインを入れておけば、geoip 判定を 1 回省けます。

完全な判定順序は次のとおりです:

1. ドメインが domain リストに該当 → fallback の結果を直接使用。
2. nameserver が返した IP が geoip-code(CN)に該当 → nameserver の結果を使用。
3. 返された IP が ipcidr に該当 → nameserver の結果を使用。
4. 上記のいずれにも該当しない(IP が海外)→ fallback で再解決し、fallback の結果を優先。

この判定のコストとして、海外ドメインは解決のたびに fallback クエリが 1 回増える可能性があり、DoH の TLS ハンドシェイクが初回パケットの遅延を押し上げます。遅延に敏感なシナリオでは、nameserver-policy で個別のドメインに直接リゾルバーを指定し、一連の判定を回避できます:

  nameserver-policy:
    '+.baidu.com': 223.5.5.5
    '+.taobao.com': 223.5.5.5
    '+.google.com': https://8.8.8.8/dns-query

TUN モードの DNS ハイジャック:Fake-IP との併用が必須な理由

TUN モードはすべての IP トラフィックを仮想ネットワークインターフェースに取り込むため、一見 DNS クエリも掌握されるように思えます。しかし、システムのリゾルバーはルーターのアドレス、ISP の DNS、アプリ内蔵の DoH など、任意の DNS サーバーにクエリを送る可能性があります。これらのトラフィックは TUN に入っても、内蔵 DNS を経由するとは限りません。

dns-hijack はこの穴を埋めるものです。仮想ネットワークインターフェース上で 53 番ポート宛ての UDP と TCP トラフィックをすべて傍受し、強制的に内蔵 DNS へリダイレクトします。

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

ハイジャックは「DNS クエリをカーネルに取り込む」問題を解決します。次に解決すべきは「ドメイン情報を接続フェーズまで持ち込めるか」という問題で、これが enhanced-mode の役割です。

fake-ip モードでは、内蔵 DNS がクエリに対して 198.18.0.0/16 予約レンジのダミーアドレスを返し、同時にカーネルがドメインとダミーアドレスのマッピングを記録します。アプリはダミーアドレスで接続を開始し、トラフィックが TUN に入ると、カーネルがマッピングから元のドメインを復元してルールマッチングに渡します。DOMAIN-SUFFIX や DOMAIN-KEYWORD などのルールはこれにより引き続き有効です。

redir-host モードでは、内蔵 DNS が実際のアドレスを返します。アプリは実際の IP に直接接続し、トラフィックが TUN に入る時点では IP パケットしかないため、ルールマッチングに使えるドメインがなく、GEOIP や IP-CIDR でフォールバックするしかありません。CDN ドメインや正確な分流が必要なシナリオでは、ルールが広範囲に機能しなくなります。このモードはシステムプロキシでは問題ありません。ドメインは HTTP CONNECT リクエストが運ぶからです。問題が生じるのは TUN モードだけです。

結論:ハイジャックはクエリをカーネルに取り込み、fake-ip はドメインを失わないようにします。どちらかが欠けると、「すべてのルールが直結になる」または「すべてのルールがプロキシになる」という両極端な現象が発生し、ログから原因を特定するのも難しくなります。

fake-ip にはもう 1 つの関連フィールド fake-ip-filter があります。実際のアドレスが必要なドメインは除外する必要があります。LAN 内のデバイス、.lan と .local サフィックス、ローカルサービスのドメインをここに書かないと、ダミーアドレスを受け取ってアクセスできなくなります。

そのまま使える完全な設定例

前述のフィールドを 1 つの実用的な設定にまとめます。値の選定ロジックは次のとおりです。nameserver には中国国内の通常 DNS を置いて速度を確保し、fallback には海外の DoH を置いて汚染ドメインを修正できるようにし、fake-ip で TUN モードでもドメインルールを有効にし、dns-hijack は any:53 ですべての DNS トラフィックをカバーします。

dns:
  enable: true
  listen: 0.0.0.0:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - 127.0.0.0/8
    domain:
      - '+.google.com'
      - '+.youtube.com'
      - '+.github.com'

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

設定後、次の 6 箇所を順に確認するのが DNS 問題の標準的なトラブルシューティング手順です:

• default-nameserver は省略できません。DoH サーバー自身のドメインを解決する役割があり、欠けると doh.pub のようなドメイン形式の DoH が接続を確立できません。IP 直書きの 1.1.1.1 は影響を受けませんが、入れておく方が安全です。
• dns-hijack には any:53 を書き、8.8.8.8:53 は書かないでください。後者はそのアドレス宛てのクエリしかハイジャックせず、システム DNS が変わるとすぐに機能しなくなります。
• fake-ip-filter には必ずローカルネットワークのドメインを除外してください。そうしないと LAN 内のデバイスが正常にアクセスできなくなります。
• TUN モードで redir-host は使わないでください。ドメインルールが機能しなくなるのは、「ネットワークにはつながるが分流がすべて間違っている」最も一般的な原因です。
• 53 番ポートが使用中の場合は、listen を 127.0.0.1:5353 に変更し、システム DNS も同時に変更してください。片方だけ変更しないでください。
• 設定変更後はまずデバッグログの dns 出力を確認し、その後に dig や nslookup で内蔵 DNS にクエリを送り、返ってくるのがダミーアドレスか実アドレスかを確認してください。

DNS 設定に万能テンプレートはありません。あるのは一貫したロジックだけです。nameserver は速度を担当し、fallback は正確性を担当し、fallback-filter が切り替えのタイミングを決め、fake-ip がドメイン情報をルールマッチングに届けます。この順序で確認すれば、ほとんどの名前解決の異常は特定のフィールドに絞り込めます。