なぜ「プロキシしたのに実 IP」に見えるか

多くのユーザーが Clash でシステムプロキシまたはTUNを有効にすると、HTTP(S) の一般ブラウジングは期待した出口に乗りやすくなります。一方で「IP を表示する診断サイト」や一部のWebRTC を使う速度診断では、ページ上に自宅回線やキャリアのグローバルアドレスが併記されることがあります。これは単に「Clash が壊れている」と決めつける前に、測っているレイヤーが違う可能性が高い、というのが現場の最初の整理です。典型は WebRTC が、HTTP のプロキシ経路とは別にピア検出用の候補（ICE candidate）を露出させるケースです。また似た見え方は、IPv6 二重スタックと DNS のズレ、またはブラウザ／OS の Secure DNS が Clash の dns と二重になっている場合にも起こります。層を同時にいじるより、まず「WebRTC テスト」と「通常の HTTP の IP 表示」を別カードとして読むと迷いが減ります。

ℹ 用語のメモ：本稿の「漏洩」はプライバシー評価の一般論ではなく、ユーザーの期待（ブラウザの表示 IP＝プロキシ出口）と、サイトが取得した候補情報のギャップを指します。診断の目的は攻撃ではなく、設定の整合を確認することです。

WebRTC が載せる ICE 候補の話

WebRTC はリアルタイム通信のため、UDP／TCP のソケットを組み合わせて最適な経路を探します。その過程でブラウザは「この端末のローカルアドレス」「NAT の外側に見える反射アドレス」「必要なら TURN」などをICE 候補として集めます。利用者から見ると、これが診断ページにISP やルータの見え方として並ぶことがあり、HTTP プロキシで覆ったつもりでも別カテゴリの情報として残ります。対策の基本は、ブラウザ側で WebRTC の挙動を制限／無効化に近づけるか、あるいは拡張機能で候補取得を抑えることです。企業端末ではグループポリシーやセキュリティソフトが先行するため、許可と手順書に沿ってください。

ブラウザ側の最小対策（Chrome／Edge／Firefox）

UI の名称は更新で変わるため、ここでは探索キーワードで案内します。Chrome／Edge（Chromium 系）では、設定の検索で「WebRTC」や「リアルタイム通信」に関連する項目、chrome://flags にある WebRTC の挙動に関するフラグ（バージョンにより名称が変化）を確認します。Firefox では about:config の media.peerconnection.enabled を false にすると、WebRTC 自体を実質的に止められることが多いです（副作用：WebRTC 依存のサービスが使えなくなる）。Safari は設定の深さが異なるため、まずは開発者向け／プライバシー設定の項目と、拡張の有無を切り分けます。いずれのブラウザでも、検証は拡張を無効化したプロファイルかシークレット＋最小拡張から始めるとブレが少ないです。

どのクライアントが自分に合うかは端末と職場ポリシーで変わるため、GUI の分かりやすさという観点では クライアント選びの整理 も併せて読むと安心です。

Clash：システム代理・TUN とブラウザの重なり

Clash 側で重要なのは、どのトラフィックが仮想インターフェース／プロキシに載る設計かを把握することです。システムプロキシだけだと、プロキシ非対応の通信や、実装差のあるスタックが残ることがあります。TUN は広く取り込めますが、他製品 VPN やゼロトラストと競合したり、除外リストの設計が必要になります。全体の設計は TUN モードの詳解 を軸に、Windows で手を付ける場合は 実機セットアップ記事 の順序も参照してください。WebRTC は「HTTP 診断のページ」と同じ見た目でも別の網で動くことがあるため、Clash のログを見るときはUDP の扱いとルールの上から順の命中に注目します。

WebRTC ではないとき（IPv6／DNS／fake-ip）

次のような場合は WebRTC より先に、IPv6／DNS／fake-ip を疑います。（1）通常の IP 表示サイトでも ISP の IPv6 が出る、（2）測速だけでなく DNS 漏洩テストで手元のリゾルバ名が出る、（3）LAN 管理画面や社内ホストだけが突然届かない。enhanced-mode: fake-ip 周辺は Fake-IP と LAN の例外とセットで読み、nameserver と fallback の整理は DNS の実践記事 に譲ります。IPv6 二重スタック全般は 当サイトの IPv6 記事 の手順がそのまま当たり板になります。

分流が期待どおりかを確認する

「プロキシ出口は見えているのに、国内サイトだけ直結したい」など、ポリシーが分割されている場合は、ルールの順番がすべてです。MATCH の一行手前までが本当に意図どおりか、ルール分流のベストプラクティス に沿って読み直し、接続ビューでドメインと実アドレスがどのポリシーに入っているかを確認します。WebRTC を止めたあとに残る「おかしい出口」は、多くの場合ここで説明がつきます。

rules: verify ordering (illustrative) 
rules:
  - DOMAIN-SUFFIX,example-test.net,PROXY
  - GEOIP,JP,DIRECT
  - MATCH,PROXY

検証サイトとログの読み方

手順はシンプルです。まず同一ブラウザで、(A) 一般の IP 表示、(B) WebRTC 特化の診断（利用するサイトは信頼できるものに限定）、を変更前後で比較します。挙動が (B) だけ改善するなら WebRTC 切り分けが当たりです。(A) と (B) の両方が変わるなら、TUN／DNS／IPv6 の面を再点検します。Clash のログでトラフィック種別が追える環境では、接続ログの読み方 を参照し、timeout や TLS のエラーが混ざっていないかも確認すると、単なる「漏洩」ではなく接続失敗の混入を避けられます。

⚠ 注意：本稿は自分が管理し、契約と社内規程で許された回線・端末での切り分けを対象とします。禁止区域での匿名化や規約回避を助長する意図はありません。

まとめ

Clash でシステム代理や TUN を有効にしても、ブラウザ診断に実 IP が並ぶときは、HTTP の経路と別にWebRTC の ICE 候補が露出している可能性が高いです。まずブラウザ側の最小変更で WebRTC を抑え、残差があれば IPv6／DNS／fake-ip と ルール順を順に疑います。分流の考え方は ルール分流、トンネル全体は TUN 詳解 に線でつながります。

設定は版やクライアントで差が出るため、画面名より症状とログの対応を残すほど再現性が上がります。

→ プロファイル編集とログを同じ画面から扱いたい方は、Clash を無料ダウンロードし、検証ループを短い単位で回せるクライアントから試してください。