一、「プロキシが効いていない」のではなく漏れ経路
多くのユーザーが最初に踏む誤解は、「IP 診断ページに実 IP が出る＝ Clash が無効」という単純化です。実際には、通常のウェブ閲覧（HTTPS）はミックスドポートや TUN 経由で出口ノードに乗っている一方、別プロトコルがプロキシスタックをすり抜けてローカル回線から STUN や DNS クエリを投げている、という非対称が起きやすいです。診断サイトは「今見えている出口 IP」と「WebRTC で覗いた候補」「DNS テストで解いた名前の経路」を別枠で表示するため、一覧のどの行がどの経路の結果かを読み分ける必要があります。
切り分けの順番としておすすめなのは、(1) ページ上で WebRTC 関連の表示があるか確認する、(2) DNS 漏洩と書かれたセクションがあるか見る、(3) それでも説明がつかなければ ルールで診断ドメインが DIRECT になっていないかログで確認する、です。GEOIP と DIRECT の分流記事で述べたように、意図せず国内直結やローカル優先に落ちると、「プロキシ ON なのに一部だけ実回線」に見えることがありますが、本稿の主役はWebRTC と DNS の取りこぼしです。
二、WebRTC と STUN：HTTPS とは別の穴
WebRTC はブラウザ内のビデオ会議や一部のリアルタイム機能で使われ、ICE 交渉のために STUN／TURN サーバへUDP（場合によっては TCP）で問い合わせます。多くのプロキシ実装では、HTTP CONNECT や SOCKS の上に載る閲覧トラフィックはうまく転送できても、生の UDP デートグラムを同じノードへ意図どおりトンネルしない構成が普通にあります。結果として STUN が「あなたの NAT の外側に見えるアドレス」を返し、診断ページがそれを実 IP 相当として表示します。これは出口ノードの IP と一致しないことが多く、まさに「プロキシは効いているのに実家の回線が見える」という体感を生みます。
対策の現実的な順序は、(1) ブラウザ設定で WebRTC のプライバシーや mDNS 関連（実装名はブラウザ依存）を確認する、(2) 信頼できる拡張で WebRTC の漏れを制限する設定があるか見る（過剰にすると会議サービスが壊れるので注意）、(3) TUN モードで UDP がカーネルレベルから同じスタックに載るかを検討する、です。Discord の UDP／WebRTC 記事ではデスクトップアプリを例にしていますが、「HTTPS とは別に UDP が抜ける」という発想はブラウザでも同じです。
三、Clash の DNS と「誰が名前を聞くか」
DNS 漏洩とはざっくり言うと、ドメイン名の問い合わせが、あなたが期待するプロキシ経路ではなくISP やルータの DNSへ直行し、その結果がテストサイトに覗かれる状態です。Clash では dns: ブロックで enhanced-mode（fake-ip や redir-host）、nameserver、fallback、nameserver-policy などを定義しますが、OS のネットワーク設定がまだルータの DNS を向いている、TUN の DNS ハイジャックがオフ、クライアントが「システム DNS に従う」になっているなどのズレがあると、ブラウザの一部リクエストだけ別解決になります。
実務的には、(1) GUI で システムプロキシ／TUN／仮想 DNSのどれを有効にしているかを一つに固定し、(2) dns.enable: true と上流の到達性を確認し、(3) 問題が続くときは fake-ip と DNS の排障記事の順で fake-ip-filter と fallback を見直す、が安全です。本稿の焦点は「サイトが開かない」より診断ページに載る解決経路の表示なので、ログに出る DNS クエリの宛先と、テストサイトが言う「どの DNS を使ったか」を突き合わせます。
# dns: ブロックのイメージ（キー名は利用コアのドキュメントに合わせる）
dns:
enable: true
listen: 0.0.0.0:53
enhanced-mode: fake-ip
nameserver:
- https://dns.example/dns-query
fallback:
- tls://dns.example:853四、ブラウザの DoH／Secure DNS と二重解決
Chrome や Edge、Firefox は、OS の DNS を使わずブラウザ内蔵の DoH（Secure DNS）で名前解決するモードを持ちます。このとき Clash の fake-ip が返す仮想アドレスと、ブラウザがクラウド DNS から得た実アドレスが食い違うと、診断ページや開発者ツールの表示が混乱し、ユーザーには「DNS が漏れている」ように見えます。対処の基本は、(1) テスト時だけブラウザの Secure DNS をオフまたは「システムの既定」に戻し、Clash 側の DNS ポリシーと単一化する、(2) 逆に Clash を信頼するなら、OS のネットワークアダプタ DNS を 127.0.0.1（クライアントのドキュメントに従う）へ寄せ、ループや奪取順序に注意する、の二択です。
モバイル OS では「プライベート DNS」や端末メーカー独自の省電力 DNS が加わるため、PC より二重解決が起きやすい点に留意してください。WSL2 とホストの DNS 記事は別コンテキストですが、「同じマシンでも名前解決の担当者が複数いると壊れる」という教訓は共通です。
五、ルール分流：診断サイトが DIRECT になっていないか
ルールセットによっては、速度計測や CDN テスト系のドメインが国内最寄りの DIRECT に落ちるテンプレートがあります。これは悪意ではなく体感速度優先の設計であることが多いですが、ユーザー目線では「プロキシを選んでも診断だけ実回線」と読めてしまいます。ログで該当ホストが PROXY か DIRECT かを確認し、意図どおりかを見ます。診断だけ出口を揃えたい場合は、ルールの上書きや別プロファイルでテストする方が、グローバル設定を壊しにくいです。
| 画面の見え方 | まず疑う層 |
|---|---|
| WebRTC 欄だけ自宅っぽい IP | STUN／UDP のプロキシ外、TUN 未使用、ブラウザのプライバシー設定 |
| DNS テストだけ ISP の名前 | ブラウザ DoH、OS DNS、Clash dns ハイジャックの不一致 |
| HTTPS の出口 IP はノードなのに表示が混在 | 診断サイトが複数経路を並列表示；ルールでドメイン別に出口が分かれている |
六、TUN・システムプロキシ・拡張機能
システムプロキシだけ有効にしていると、ブラウザの HTTP(S) はローカルの Clash に向きやすい一方、UDP を伴う WebRTC は別経路に落ちやすいです。TUN モードはカーネルのルーティングに介入するため、UDP まで含めて同じポリシーに載せやすい反面、企業 LAN や既存 VPN とルート競合しやすいというトレードオフがあります。TUN と Windows のルート記事で全体断やループを先に潰してから、本稿の WebRTC／DNS の話に戻ると手戻りが減ります。
さらに、広告ブロッカーや「指紋対策」系の拡張が、WebRTC や DNS を意図的に書き換えていると、診断結果が日々変わります。拡張をオフにしたプロファイルで一度ベースラインを取ってから、Clash 側を触ると原因が切り分けやすくなります。
七、まとめ
Clash をオンにしているのにブラウザの IP 診断で実 IP が出るとき、最初に疑うのはノードの死活ではなく、WebRTC の STUN がプロキシ外に出ているかと、DNS クエリがブラウザ DoH・OS・Clash のどこで処理されているかです。HTTPS の出口と WebRTC／DNS の表示は別物として読み、対照実験では一度に一層だけ変えてください。
ルール分流や fake-ip の細部は fake-ip／DNS の記事、マシン全体の取り回しは ドキュメントのテンプレと合わせて確認すると、設定の意図が腹落ちしやすくなります。
適切なクライアントとプロファイルが揃えば、表示の混乱はかなり減らせます。安定したルールベースのプロキシ運用を試したい方は、まず公式の入手経路から環境を整えてみてください。