洩漏檢測 · 技術說明

WebRTC 洩漏是什麼

WebRTC 是瀏覽器內建的即時通訊能力，用來支援視訊會議、語音通話、P2P 檔案傳輸等場景。為了建立點對點連線，瀏覽器會通過 STUN 伺服器發現自己在公網側看到的地址。這個探測通常使用 UDP，而普通 HTTP / SOCKS 代理並不一定接管 UDP。

如果 STUN 請求繞過代理直接從本地網路發出，網頁尾本就可能拿到你的真實公網 IP。這個過程通常不需要攝像頭、麥克風許可權，也不會彈出額外確認框，所以它常被用來檢查代理是否真正覆蓋了即時通訊流量。

如何判斷結果

發現洩漏後怎麼處理

• 代理客戶端改用 TUN 模式，讓 WebRTC 的 UDP 也走代理出口。
• Chrome / Edge 設企業策略 <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code>；Firefox 在 <code>about:config</code> 開啟 <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code>。不要直接刪掉 WebRTC，缺少 WebRTC 本身就能被識別。
• Brave 可將 WebRTC IP 處理策略設為“停用非代理 UDP”。
• 需要使用會議或語音時，優先在代理客戶端中修正 UDP / STUN 分流規則。

多個出口 IP 不一定是洩漏

如果你配置了分流，不同 STUN 伺服器可能會走不同節點。例如 Google STUN 走美國出口，Cloudflare STUN 走香港出口。這類結果不一定危險，關鍵是看它是否符合你的規則設計。真正需要警惕的是：所有 WebRTC 地址都指向你的物理所在地或本地 ISP。

DNS 洩漏同樣重要

WebRTC 洩漏暴露的是 "你的真實 IP", DNS 洩漏暴露的是 "你查詢過哪些域名". 如果 DNS 請求沒有走代理, 本地營運商或上游解析器仍能看到你訪問過哪些站點.

本頁的 DNS 洩漏檢測是真探針: CleanIP.io 在美國猶他州 (ns1) 和美國洛杉磯 (ns2) 各執行一臺權威 NS, 服務於 dp.cleanip.io zone. 瀏覽器每次檢測會解析 8 個獨立 <uuid>.dp.cleanip.io 子域, 這些查詢經過你系統的 stub resolver -> ISP / VPN / 公共遞迴, 最終落到我們的權威 NS, 把發起查詢的 resolver IP 和 (若有) EDNS Client Subnet 一起記錄, 再返回給你做比對.

重點看兩個訊號: ① ECS 子網 — 若遞迴 resolver 轉發了你的終端子網 (常見於 Google 8.8.8.8), 那子網就是確鑿的客戶端身份; ② resolver 國家 — 公共遞迴 (1.1.1.1 / 8.8.8.8) 跨國 anycast 是正常的, 關鍵看你以為開了 VPN 時, resolver 的位置是否跟 HTTP 出口同國家.

代理模式與 TUN 模式為什麼結果不同

HTTP / SOCKS 代理通常只處理 TCP，STUN 所需的 UDP 可能無法傳送，所以頁面可能顯示“未洩漏”。這並不代表 UDP 已被安全代理，只是 UDP 沒有成功到達 STUN 伺服器。TUN 模式會接管虛擬網絡卡上的 TCP 和 UDP，因此更能反映真實的 UDP 出口路徑。