目次
検査ページに家庭内のプライベートアドレスが出たり、ノード名と違う地域が表示されたりすると、漏えいが心配になります。表示がサイトから見える接続元なのか、名前解決サーバーなのか、ブラウザーが見つけた通信用アドレスなのかを区別し、直接接続と比較します。プロキシを迂回したと確認できるリクエストだけを対処し、会議や通常の通信も引き続き使えるか確かめます。
公開 IPv4、IPv6、DNS、WebRTC はそれぞれ何を示す？
同じブラウザーとネットワークでIPv4、IPv6、DNS、WebRTCの結果をそれぞれ記録し、利用中の通信事業者の公開アドレスを区別します。WebRTCはブラウザーの音声・映像通信に使われますが、検出したアドレスがウェブサイトから見える出口とは限りません。Clashも、これらのリクエストを自動的に同じ出口へ送るわけではありません。
同じものとして扱わないでください
| 検査項目 | 確認できること | 確認が必要な結果 | テストページ |
|---|---|---|---|
| グローバル IPv4 | Web サイトから見える出口 | プロキシを使うはずのリクエストで、利用中の通信事業者のパブリック IP アドレスが表示される | BrowserLeaks IPv4 / IPv6 |
| グローバル IPv6 | IPv6 が同じ方法で処理されているか | IPv4 はノードを通るが、IPv6 はローカルから直接送信される | BrowserLeaks IPv4 / IPv6 |
| DNS サーバー | どのサービスが問い合わせを処理している可能性があるか | 設定と一致せず、ドメインが想定したルールを迂回する | BrowserLeaks DNS |
| WebRTC の候補アドレス | ブラウザがリアルタイム通信のために検出したアドレス | 想定外の実際のグローバル出口が表示される。192.168/10.x は、それ自体ではグローバル IP のリークではない | BrowserLeaks WebRTC |
表のIPv4 / IPv6またはWebRTCのリンクを開きます。Your Remote IPのIPv4 AddressとIPv6 Address、Your WebRTC IPのLocal IP AddressとPublic IP Addressを確認してください。公開アドレスを直接接続時の記録と比較し、プライベートアドレスは表の説明に従って判断します。
DNSのリンクを開いてRun DNS Leak Testをクリックし、Your DNS Serversの一覧を記録して、設定と直接接続時の結果に照らし合わせます。JavaScript Disabledの表示、空の結果、未完了のテストから、漏洩がないとは判断できません。
直接接続、システムプロキシ、TUN を一度ずつテストする
検査ページだけで結論を出すことはできず、変更前後の二つの結果を比較して初めて意味があります。同じブラウザ、同じネットワーク、同じ検査ページを使い、Clash のトラフィック処理方法だけを変更して、四項目の結果を並べて保存してください。
比較可能なテスト
プロキシを完全に終了し、直接接続の状態を記録する
IPv4、IPv6、DNS、WebRTC の四項目を保存し、緑色の結果一つだけをスクリーンショットにしないでください。
システムプロキシを有効にする
新しいプライベートウィンドウでもう一度検査し、ブラウザリクエストの出口が変わったことを確認します。
必要な場合は TUN を有効にする
同じネットワークとノードで引き続きテストし、IPv6 と、システムプロキシを読み込まないアプリケーションを確認します。
毎回、接続ページを確認する
検査対象のドメインが表示され、ルールと出口が一致して初めて、その結果を現在の Clash 設定と関連付けられます。
Chrome の DNS 結果だけが異なる場合は、セキュア DNS を確認する
Chrome では「設定 → プライバシーとセキュリティ → セキュリティ」からセキュア DNS を個別に有効にできます。Firefox の DNS over HTTPS はプライバシー設定にあります。ブラウザで個別の DoH を有効にすると、問い合わせがシステム DNS を経由しなくなる場合があり、Clash のシステムプロキシではその名前解決リクエストまで処理できるとは限りません。
ブラウザーの DoH を短時間無効にし、完全に終了してから開き直します。DNS の結果が Clash で想定した問い合わせ先に戻れば、ブラウザーの名前解決設定が今回の結果に影響しています。その後はブラウザーで処理するか Mihomo に任せるかを選び、ブラウザー、システム、コアの名前解決設定を同時に変えないようにしてください。
WebRTC のプライベートアドレス表示と公開アドレスの露出はどう違う？
WebRTC は音声、映像、ピアツーピア通信のために候補アドレスを収集します。現在のブラウザでは、ローカルアドレスを mDNS 名で隠すことも、プライベートネットワークを表示することもあります。これらの情報から LAN 環境を確認できますが、インターネットからコンピューターへ直接ルーティングできるわけではありません。
対処が必要なのは、プロキシを使うはずのリクエストで、通信事業者のパブリック IPv4 または IPv6 が相手に見える場合です。WebRTC を完全に無効にすると、ブラウザーの会議や画面共有が使えなくなります。まずブラウザーのアドレス制限を使い、Zoom、Meet、Slack Huddle で機能を再確認してください。
IPv4 はノード経由、IPv6 は直接接続なら、取り込み設定を確認する
システムプロキシは通常、アプリケーションから明示的に渡されたリクエストを処理しますが、すべての IPv6 接続を処理する保証はありません。TUN が IPv6 を処理するかどうかも、クライアントのバージョン、ルート、設定に依存します。まず業務で IPv6 が必要か確認してください。処理できない場合に一時的に IPv6 を無効にして比較するほうが、ルールの末尾へむやみに REJECT を追加するより、原因を判断しやすくなります。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
# 若明确需要 IPv6，应改为让当前 TUN 与规则完整接管，
# 而不是长期依赖 ipv6: false。グローバルIP、DNS、プライベートアドレスをどう判断し、対処する？
グローバル IPv4 が引き続きローカルの出口になる
ブラウザーのリクエストが想定したプロキシノードを通っていません。システムプロキシ、拡張機能、適用されたルールを確認してください。
IPv4 はノードを通り、IPv6 はローカルの出口を通る
TUN の IPv6 ルートを確認します。IPv6 が不要な場合は、OS 所定の方法で無効にして比較できます。
DNS だけが想定と異なる
ブラウザの DoH、システム DNS、Mihomo DNS のどれが実際に処理しているか確認します。
LAN のプライベートアドレスだけが表示される
実際のグローバル候補がほかにもないか先に確認し、プライベートアドレスだけでリークと判断しないでください。