DNSリークのトラブルシューティングは、1つのスクリーンショットを信じて止まってしまうとうまくいきません。信頼できる方法は、ClashXの実行時設定、macOSのレゾルバ状態、ブラウザのDNS動作、そして独立したリークテストという多層的な検証です。
このガイドでは、具体的なコマンド、解釈のパターン、そしてプロファイル変更のたびに再利用できるワークシートを含む、再現可能なチェックリストを提供します。
DNSリークとは何か
DNSリークとは、ドメインのルックアップが意図しないリゾルバパス（通常は地元のプロバイダーのDNS）を通じて解決されてしまうことを指します。これはClashXのポリシーやアウトバウンドパスで期待されるルートをバイパスしてしまいます。
トラフィックの出口がプロキシ化されているように見えても、DNSのメタデータが地元のレゾルバの身元を露呈させている場合、プライバシーと地理位置情報の不整合は解消されていません。
| 検出結果 | 意味 |
|---|---|
| リゾルバ ASN = 地元のプロバイダー | システムまたはブラウザ層でのリークの可能性が高いです |
| リゾルバの国 != プロキシ出口の国 | スプリットパスまたはブラウザのDoHオーバーライドの可能性があります |
| リゾルバが地元とリモートの間で回転する | 複数のインターフェースまたは不安定なリゾルバポリシーです |
| 1つのテストサイトだけ不一致、他は合格 | キャッシュの影響またはプロバイダーの誤検出の可能性があります |
| ブラウザがプライベートDoHプロバイダーのホスト名を表示 | ブラウザが基本的なシステムDNSパスをバイパスしている可能性があります |
- 出口IPはリモートだが、DNSリゾルバが地元のプロバイダーに属している。
- プロファイルの編集なしに、更新するたびにリゾルバ出力が変わる。
- ターミナルのDNS状態とリークダッシュボードの結果が繰り返し矛盾する。
- 一方のブラウザは失敗するが、もう一方は合格する。
重要なClashX DNS設定
ほとんどのリーク事案は、不完全なDNSプロファイルブロックから始まります。最適化の前に、確定的なベースラインから構築してください。
推奨されるベースライン設定
dns:
enable: true
listen: 0.0.0.0:53
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
use-hosts: true
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback:
- tls://8.8.8.8:853
- tls://1.0.0.1:853
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
domain:
- +.google.com
- +.facebook.com偶発的なバイパスを避けるためのルールベースライン
rules:
- DOMAIN-SUFFIX,local,DIRECT
- DOMAIN-SUFFIX,lan,DIRECT
- DOMAIN-KEYWORD,intranet,DIRECT
- GEOIP,LAN,DIRECT
- MATCH,PROXY- ClashXによるDNS管理を期待しているのに
dns.enable: falseになっている。 - DoHエンドポイントが死んでいて、システムレゾルバへのサイレントフォールバックが発生している。
fake-ip-filterのエントリが広すぎて、バイパスパスが強制されている。- 異なるプロファイル生成から混ざったスニペットを使用している。
より強力なルーティングパフォーマンスとスケーラビリティのためには fake-ip を使用してください。互換性が実際のDNSマッピングを要求する場合は redir-host を使用します。リーク分析では、両方のモードを一度テストし、違いを記録してください。
システムネットワーク層の確認
YAMLが正しくても、macOSのリゾルバ優先順位が古かったり重複していたりすると失敗することがあります。Webダッシュボードを信頼する前に、システムの状態を検証してください。
ターミナルコマンド
scutil --dns
networksetup -getdnsservers Wi-Fi
networksetup -getdnsservers Ethernet
route -n get default
lsof -nP -iUDP:53
lsof -nP -iTCP:53 -sTCP:LISTENステップバイステップの確認
- 不要なインターフェースや仮想アダプターを無効にします。
- プロファイルを適用し、モード（RuleまたはGlobal）を確認します。
- ベースラインの証拠として
scutil --dnsの出力を取得します。 networksetup -getdnsserversでインターフェースのDNSを検証します。- 2つのリークサイトを実行し、コマンド出力と比較します。
- インターフェースを1つずつ再度有効にして、相違点を特定します。
Wi-Fi、Ethernet、VPNアダプター、エンドポイントフィルターがすべてレゾルバデータを登録することがあります。分離しないと、結果が交互に入れ替わり、ランダムに見えることがあります。
ブラウザのDoHによる影響
ブラウザのDNS over HTTPS (DoH) は、ルックアップをブラウザが選択したプロバイダーに直接ルートすることがあります。これは、ClashX + システムDNSのルーティングが本当に正しいかどうかを隠してしまう可能性があります。
DoHはブラウザのプライバシーを向上させますが、テストの意味を変えてしまいます。ベースラインの検証では、まずDoHの状態を正常化し、その後で意図的に再度有効にしてください。
Chrome
chrome://settings/securityを開きます。- セキュア DNS を使用する を探します。
- 現在のサービス プロバイダを使用する に設定するか、ベースライン確認のために無効にします。
- キャッシュをクリアし、リークテストを再実行します。
Firefox
about:preferences#privacyを開きます。- DNS over HTTPS を見つけます。
- ベースライン確認のために オフ に設定し、ポリシーモードで再テストします。
about:networking#dnsを使用してDNSキャッシュを調査し、クリアします。
Edge
edge://settings/privacyを開きます。- セキュリティ項目内のセキュアDNS設定を探します。
- テストマトリックスに合わせてモードを設定します。
- 新しいセッションでテストを実行します。
ターミナルの出力は期待通りなのに、ブラウザのリークテストが異なるレゾルバを表示する場合、おそらくブラウザのDoHがベースラインのDNSルーティングをオーバーライドしています。
検証ワークシート
一貫した記録は、DNSのトラブルシューティングを運用プロセスに変えます。プロファイルの更新、アプリの更新、ネットワークの切り替え後にこのワークシートを使用してください。
検証テンプレート
検証セッション ID: ______________________
日付 / 時刻: ________________________________
ネットワーク: 自宅 / オフィス / モバイルホットスポット
プロキシモード: Rule / Global / Direct
プロファイルバージョン: ____________________________
期待されるDNSリゾルバ地域: _______________
期待される出口IP地域: ____________________
ブラウザ DoH 状態: オン / オフ / プロバイダー: _____
テスト #1 (dnsleaktest.com)
- リゾルバ ASN: _____________________________
- リゾルバの国: _________________________
テスト #2 (ipleak.net)
- DNS エントリ: ______________________________
- IP 地域: ________________________________
テスト #3 (browserleaks.com)
- DNS 結果: _______________________________
- WebRTC 露出: はい / いいえ
ターミナルの証拠
- scutil --dns スナップショット保存済: はい / いいえ
- networksetup 出力保存済: はい / いいえ
判定
- リーク確認済: はい / いいえ
- 根本原因の仮説: _____________________
- 次のアクション: _______________________________- 1つのインターフェースをアクティブにし、1つのブラウザプロファイルを使用します。
- テストサイトを訪れる前にターミナルのDNS状態を取得します。
- 3つすべてのリークツールを実行し、各リゾルバの結果を記録します。
- ブラウザのDoHを切り替え、影響を定量化するために繰り返します。
- ClashXの変数を1つずつ変更し、再テストします。
よくある誤検出
すべての不一致がリークではありません。本番ポリシーを変更する前に、変数を制御し、各層で証拠を照合してください。
キャッシュされた記録は、プロファイルの切り替え後も残ることがあります。ブラウザのDNSキャッシュをクリアし、ユニークなサブドメインで再テストしてください。
プロバイダーによっては、設計上、地域的に近いレゾルバを返すことがあります。リークと断定する前に、ASNの所有権を検証してください。
セキュリティソフトウェアがローカルのDNSプロキシ動作を注入することがあります。結論を出す前に、リスナーとリゾルバチェーンを調査してください。
IPv6のDNSパスがIPv4のポリシーから逸脱することがあります。両方のファミリーを独立して比較してください。
リゾルバASN、ターミナル出力、ブラウザのDoH状態の3つの信号を合わせて確認してください。1つだけ失敗した場合は、疑わしいと分類し、管理された条件下で再実行してください。
よくある質問
1. DNSがリークしている間、出口IPが正しく見えることはありますか？
はい。出口IPとDNSパスは別々のコントロールプレーンです。出口IPが正しくても、地元のリゾルバメタデータが露出していることがあります。
2. ブラウザのDoHは恒久的に無効にしておくべきですか？
いいえ。ベースライン診断の間だけ無効にし、その後はセキュリティポリシーに従って再度有効にしてください。
3. fake-ip は常に redir-host より優れていますか？
常にではありません。通常は fake-ip の方が高速ですが、機密性の高いアプリケーションでは redir-host の方が互換性を向上させることがあります。
4. なぜリークサイトによってリゾルバの結果が異なるのですか？
異なるインフラストラクチャとデータセットを使用しているためです。複数のソースを比較し、ターミナルの証拠と相関させてください。
5. このチェックリストはどのくらいの頻度で繰り返すべきですか？
プロファイルの更新、アプリの更新、ブラウザのDNSポリシー変更、大幅なネットワークの移行後に行うのが良いです。
6. 根本原因を特定するための最短ルートは？
変数を固定してください：1つのインターフェース、1つのブラウザプロファイル、1つのClashXプロファイル。まずコマンドでの証拠を取得し、その後にリークダッシュボードを実行します。
シナリオ別Q&A：ターミナルとエンタープライズネットワーク
Q1: ターミナルで Git/npm がタイムアウトしますが、ブラウザは動作します。これは常にDNSリークですか？
いいえ。まず TUNモード とシェルのプロキシ変数を確認してください。これは純粋なリークではなく、パスの分割によるものであることが多いです。
Q2: エンドポイントセキュリティソフトウェアがDNSをオーバーライドします。ClashXでリークを防げますか？
はい、まず各層でDNSの所有権をマッピングすれば可能です。クリーンなベースラインを構築し、エンタープライズツールを1コンポーネントずつ再度有効にしてください。
Q3: DNSは健全に見えますが、アクセスが不安定です。次は何をすべきですか？
ルールのヒット順序も確認してください。広すぎるルールはDNSの問題のように見えることがあります。相互検証のために ルール優先順位ガイド を活用してください。
まとめ
DNSリーク防止は再現可能なワークフローです：安定したClashX DNSベースラインを構築し、システムレゾルバの順序を検証し、ブラウザのDoH動作を制御し、書面での検証記録を保持します。
層状のチェックを行うことで、プロファイルのアップグレードやネットワーク環境の変化に関わらず、リーク診断は客観的かつ迅速に進めることができます。