代理通常只覆蓋 HTTP 流量，而 WebRTC 會透過 STUN/ICE 以 UDP 交換候選位址。本文說明何時可能暴露本機與內網位址，以及如何讓網路出口與瀏覽器環境保持一致。
代理已經設定好，IP 查詢頁面顯示的地區與電信業者都符合預期，看起來網路身分已經處理乾淨。但打開洩漏檢測頁面後，WebRTC 那一欄卻顯示紅色，出現的是你真實電信業者的出口位址。
先不用急著更換代理。多數情況下，問題不在代理品質，而是在代理管不到的流量。
代理只處理 HTTP，WebRTC 走的是另一條路
代理工作在網路層。無論它是瀏覽器擴充功能還是系統層級的隧道，處理的主要都是 HTTP/HTTPS 請求，並把這一路流量從代理出口送出去。
WebRTC 則不同。它是瀏覽器內建的即時通訊能力，為了讓音訊、視訊通話與 P2P 傳輸找到合適的路徑，瀏覽器可能主動向外部伺服器發出 STUN 查詢——本質上是在問「從你那邊看，我的位址是什麼？」——接著把結果整理成 ICE 候選並交給網頁。這些查詢使用 UDP，和 HTTP 隧道是彼此獨立的通道。
因此會出現不一致：網頁請求從代理出口離開，但瀏覽器同時也可能回報本機位址。以為代理設定完成就代表整體網路身分已經乾淨，是這類問題最常見的起點。
洩露的不只可能是公網 IP
ICE 候選通常包含兩類位址。一類是公網位址，也就是你真實電信業者的出口；另一類是本機位址，例如以 192.168 開頭的內網位址，有時也可能包含虛擬網路卡的位址。
內網位址單獨看並不能說明太多，因為幾乎每台電腦都有。但它可能足夠穩定，當多個帳號的候選位址反覆重疊時，平台就多了一個可用來把這些帳號關聯到同一台裝置的訊號。公網位址更直接，它會指向真實電信業者與大致地理位置。能細到什麼程度取決於對方的實作，但方向很清楚：位址越真實，關聯越容易。
什麼情況下網站真的會讀到
並不是每個網站都會嘗試讀取。位址交換需要頁面主動建立 RTCPeerConnection 物件，一般內容頁通常不需要這麼做。
比較常見的是幾類網站：需要即時通訊的服務，例如視訊會議、線上客服與部分直播頁面；高度依賴廣告或反詐欺的網站；以及風險控管系統較完整的平台。這些讀取通常發生在前端看不見的位置，資料蒐集後會怎麼使用，也通常不會另外通知你。
另外還有一種和網站本身無關的情況。代理重新連線或切換節點的短暫空檔裡，瀏覽器發出的 STUN 請求可能會落到本機網路。時間雖然很短，但已足以被記錄一次。
三種常見的失效情況
瀏覽器擴充功能類型的代理通常只接管 HTTP/HTTPS 請求，UDP 不在它的處理範圍內；即使在介面上勾選「全域」也不會改變這一點。
系統層級的全域代理看起來更徹底，因為它覆蓋整台裝置的流量。但候選位址的蒐集可以直接綁定本機網路介面，繞過系統路由表，因此隧道在這個環節仍可能留下缺口。
第三種不是單純的技術問題，而是風控節奏的改變。風險控管系統逐漸把 WebRTC 位址納入帳號關聯的參考訊號之一。過去沒有量測、或不重視的資料，現在可能已經被算進判定。
方向是讓出口自洽，而不是只關掉一個開關
大致有幾種處理方式。如果業務完全不需要即時通訊，直接停用 WebRTC 最簡單，但代價是視訊通話、線上客服之類的功能也會一起無法使用。
如果需要保留功能，常見做法是讓 WebRTC 層回傳的位址與代理出口保持一致。更穩妥的方式，是連 STUN 請求也一起送進代理通道轉送，避免介面暴露本機位址。若有 P2P 或視訊通話需求，則應讓整體 UDP 流量都走代理，而不是只處理 HTTP 這一層。
容易誤解的地方是：單獨關閉 WebRTC，不代表整個環境就乾淨了。真正要確保的是網路出口、DNS 解析、IP 歸屬與 ASN、時區與語言、裝置特徵彼此一致。任何一項對不上，都可能留下異常訊號；WebRTC 只是其中最容易被忽略的項目之一。
驗證方式很簡單。切換節點後測一次，在正式使用前再測一次：打開洩漏檢測頁面，查看 WebRTC 欄位回傳的是代理出口、本機位址還是真實公網位址。一般 IP 查詢看不出這一項。
瀏覽器核心層的環境隔離方案，可以為每個環境單獨設定 WebRTC 位址策略，並與該環境綁定的網路出口搭配。PurpleMark 提供的就是這類能力。如果多個環境共用同一個出口，或各環境的位址策略彼此不一致，隔離的價值就會大幅下降。
以上僅為技術原理說明，請在遵守平台規則與當地法律的前提下使用相關工具。
