使用代理仍暴露IP？WebRTC洩漏檢測與防護指南
一般IP頁面顯示代理，但WebRTC測試列出另一個IP或.local名稱。這不一定代表洩漏，必須先確認ICE候選類型與實際路由。
本文於2026年7月複核。瀏覽器、代理或網路變更後都應重新測試。
為何路徑可能不同
HTTP代理通常處理網頁請求；WebRTC則為音視訊與資料通道，從本機介面、STUN和TURN收集ICE候選，並可能使用UDP或TCP。若UDP或IPv6沒有進入代理，STUN可能看到原始網路的公網映射。
| 類型 | 判讀方式 |
|---|---|
host | 本機介面、私有IP、IPv6或mDNS；單獨出現不代表公網洩漏 |
srflx | STUN發現的NAT映射；此處出現原電信商公網IP是強證據 |
prflx | 連線檢查時發現的候選 |
relay | TURN伺服器地址，不是終端公網IP |
W3C指出ICE候選可能揭露位置、網路拓撲並增加指紋面。參閱WebRTC IP隱私說明。
可重現的檢測
- 私下記錄原始IPv4與IPv6基線。
- 啟用代理，重啟環境並檢查HTTP、DNS、IPv4與IPv6。
- 收集含
type、protocol和地址的候選。 - 與原始IP、代理出口及TURN比較。
- 每次修改後完整重啟再測。
srflx包含原電信商公網IP表示明顯風險；私有IP或.local是host/mDNS，需進一步判讀；relay代表TURN。參閱MDN候選類型。
防護方式
使用明確涵蓋所需UDP與IPv6的隧道，檢查split tunneling，支援時限制非代理UDP。完全禁用WebRTC會影響會議、語音與螢幕共享。網站開發者可設定iceTransportPolicy: relay並部署TURN，但會增加延遲與成本。
紫紋瀏覽器提供轉發、替換、真實、禁用和代理UDP。替換讓WebRTC IPv4符合代理出口；真實保留本機資訊；禁用阻止讀取；代理UDP禁止非代理UDP且需要Patch 2.8.2.0以上；轉發保留設定的WebRTC能力。每種模式都必須在實際網路複測。
檢查表
- HTTP出口是否為預期代理？
- IPv4與IPv6是否一致處理？
srflx是否出現原電信商IP？- 其他地址是private、mDNS、proxy還是TURN？
- 代理是否真正支援UDP？
- 必要的通話功能是否仍正常？
結語
第二個地址不等於洩漏。可靠結論需要候選類型並與原始網路及代理對照。紫紋瀏覽器可協助隔離獲授權環境，但不能取代測試，也不會改變網站規則。