WebRTC IP 洩露：換了代理為什麼還能「被打回原形」
做亞馬遜的朋友老周，花小一千買了住宅代理，用戶端裡顯示一切正常。直到有一天他在檢測網站上看了一眼，發現頁面裡同時出現了兩個 IP：一個美國，一個中國。美國的那個是他買的代理，中國的那個，是他自己家的寬頻。
他當時沒當回事。直到第三家店鋪因為「關聯」被凍結，他才想起那個詭異的頁面。
這不是個例。我幫客戶排查帳號問題時發現，大多數「換了代理還被封」的案例，問題都不在代理品質，而在瀏覽器自己的一條「後門」——WebRTC。這篇把它講透：它怎麼繞過代理、洩露了有什麼後果、怎麼自查、怎麼堵上。
WebRTC 是瀏覽器的一扇「消防通道」，代理管不著
把代理想像成社區的門衛，把 WebRTC 想像成消防通道——門衛管得住大門，管不住消防通道裡直通你家的暗門。
具體到技術層面，兩條路分工完全不同：
- 代理接管的是「網頁請求」這條大路，也就是 HTTP/HTTPS 流量。你以為「所有流量都走了代理」，其實只是網頁瀏覽這一部分。
- WebRTC 走的是瀏覽器內部的即時通訊機制，用 STUN/ICE 協定（基於 UDP）直接問外網伺服器「我的公網位址是多少」。這個過程發生在瀏覽器核心裡，代理工具根本看不見，自然也攔不住。
這就是老周那次「兩個 IP 並存」的真相：網頁請求走了美國代理，WebRTC 卻悄悄把家庭寬頻位址報了出去。
哪些場景最容易踩雷？視訊通話、語音社交、線上協作這類即時通訊功能是重災區；電商和社媒平台平時看著不觸發，但會在登入、支付這類關鍵時刻靜默探測——防不勝防。
一個 IP 洩露，怎麼牽出一整批帳號？
老周的案例就是最好的說明：
- 關聯就這麼坐實了。 第一家店鋪登入時，平台透過 WebRTC 看到了他的家庭 IP；第二家店鋪登入時，又看到同一個家庭 IP。兩個「互不相干」的店鋪背後連著同一根網線——「關聯」兩個字就這麼寫在了風控檔案裡。
- 然後就是批量處理。 關聯一旦成立，一個帳號出事，同一主體下的其他店鋪、廣告帳戶、收款帳戶全被牽連，一倒就是一片。
- 最麻煩的是洗不掉。 洩露的不只是 IP，還有真實地理位置和電信商資訊。這些資料一旦進了風控檔案，換環境、換代理都很難抹掉。
很多賣家把「換代理」當成萬能藥，恰恰忽略了：代理能換掉「網路身份」，換不掉瀏覽器自己報出去的「真實位址」。
2 分鐘自查：你的真實 IP 有沒有在「裸奔」
不用拆瀏覽器、不用裝軟體，打開任意一個 IP 檢測網站（ipleak.net、BrowserScan 都行），三步就能看清：
- 先測一次「裸奔狀態」。 掛著自己的家用網路打開檢測頁，記下頁面顯示的 IP——這是你的「真實底牌」。
- 掛上代理再測一次。 開啟代理，重新整理同一個頁面。
- 對比 WebRTC 分欄。 如果這一欄裡出現了你家用網路的 IP，說明後門開著；如果顯示的是代理 IP 或空白，說明這層防護是通的。
這裡有個大多數人都會踩的盲區：檢測頁往往同時顯示好幾欄（IP、DNS、WebRTC），很多人只盯最顯眼的「IP 一欄」，看到變成美國就放心了——真正藏雷的 DNS、WebRTC 分欄反而沒人看。
想堵上這扇後門，正確姿勢是什麼？
先說三個「想當然」的嘗試，為什麼都行不通：
- 裝攔截外掛：多數 WebRTC 攔截外掛只擋一部分觸發路徑，遇到新場景照樣漏。
- 換更貴的代理或 VPN：代理管網路層，管不到瀏覽器核心，換再貴的也沒用（這點在指紋瀏覽器 vs VPN那篇聊過）。
- 直接把 WebRTC 關掉：能堵死，但視訊通話、線上會議這些功能全廢，屬於因噎廢食。
真正治本的方案是從瀏覽器核心層處理：指紋瀏覽器直接修改 WebRTC 相關 API 的行為，讓網頁腳本拿不到你的真實位址。以 MasBrowser 為例，建立環境時在指紋設定裡把 WebRTC 選為「禁止」，瀏覽器就不會再透過 WebRTC 探測本機網路介面。完整的獨立環境與指紋隔離設定，可以在 MasBrowser 多帳號安全管理頁面 查看。
設定完再回檢測頁看一遍。 確認 WebRTC 分欄裡不再出現真實 IP，這扇後門才算真正關上。
常見問題
WebRTC 洩露和 DNS 洩露是一回事嗎？
不是。DNS 洩露是代理對 DNS 查詢處理不徹底，請求走了本地電信商；WebRTC 洩露是瀏覽器原生功能繞過代理直接報 IP。兩者都暴露真實網路環境，但路徑不同，檢測頁也是分開顯示的。
換了住宅代理，WebRTC 還會洩露嗎？
會。洩露和代理類型無關——只要瀏覽器 WebRTC 功能沒被正確處理，無論住宅還是機房代理，它都能繞過隧道報真實 IP。重點是堵住 WebRTC，不是換更貴的代理。
把 WebRTC 設成「禁止」，會影響正常使用嗎？
基本不影響。絕大多數網頁應用（電商、社媒、辦公）用不到 WebRTC；只有視訊通話、線上會議、P2P 傳輸類功能會受影響，這類場景單獨建一個不禁止 WebRTC 的環境就行。
檢測頁全綠，就絕對安全了嗎？
說明這一項防護到位了。但多帳號安全是「組合拳」：WebRTC 只是網路層一環，還要配合指紋隔離、代理綁定、行為一致性一起看，單點綠色不代表整體安全。
結語
換了代理還被封，十有八九不是代理的鍋，而是瀏覽器這扇「消防通道」沒堵上——它繞過代理，把你的真實位址直接報給了平台。
好消息是解決方案不複雜：從瀏覽器核心層處理 WebRTC，設定完再檢測一次確認。免費版就有 2 個環境配額，下載 MasBrowser，建一個環境把 WebRTC 設為「禁止」，測一次看真實 IP 是否還在——這一步，值得在每一個帳號上做。
