明明已經設定代理，IP 檢測網站卻仍顯示真實 IP？很可能是 WebRTC 洩漏。本文說明指紋瀏覽器中替換、轉發、真實、停用、代理 UDP 五種設定模式的原理與取捨，以及如何按場景選擇並驗證是否生效。
你有沒有遇過這種情況：明明已經替瀏覽器設定好代理，打開 IP 檢測網站卻仍顯示你的真實位址？問題很可能是 WebRTC 洩漏。
WebRTC（網頁即時通訊）讓瀏覽器不需要外掛就能進行音訊與視訊通話，但它在建立連線時，可能繞過代理直接暴露裝置的真實 IP。視訊會議、語音聊天、線上客服，甚至一些你注意不到的網頁腳本都可能呼叫它。這篇文章說明在指紋瀏覽器（如 PurpleMark）裡有哪些 WebRTC 設定模式、各自的取捨，以及怎麼選、怎麼驗證。
一、WebRTC 設定的 5 種模式
多帳號指紋瀏覽器通常會在「環境指紋設定」中提供幾種 WebRTC 處理方式，常見有以下五種：
1. 替換模式（Replace）—— 多數場景的預設選擇 網頁發起 WebRTC 請求時，瀏覽器回傳你為該環境設定的代理 IP，並隱藏本機真實 IP，讓「代理 IP」與「WebRTC 看到的 IP」保持一致。適合 Amazon、TikTok、Shopify、Facebook 等一般帳號的日常營運，也是最建議先嘗試的模式。
2. 轉發模式（Forward）—— 替換的進階版 透過公開 STUN 伺服器中繼 WebRTC 請求，讓請求路徑看起來像是由一般網路節點發出，而不是單純修改數值。相較替換模式更不容易被察覺，適合對連線來源驗證更嚴格的平台，例如部分交易類、支付類網站。
3. 真實模式（Real）—— 不干預 直接使用裝置的實體真實 IP，不做任何處理。通常只有在網路測試、本機開發除錯等明確需要真實環境的情況下才使用；在需要環境隔離的大量營運中，基本上不應開啟。
4. 停用模式（Disabled）—— 從源頭切斷 直接關閉瀏覽器的 WebRTC 能力，網站無法發起任何 WebRTC 請求，從根源上消除這類洩漏。代價是依賴攝影機、語音的網站，例如網頁版語音或線上客服，可能無法使用。適合隱私要求很高、又不依賴網頁音訊與視訊通訊的場景。
5. 代理 UDP（停用 UDP）—— 更底層的協定控制 WebRTC 主要依靠 UDP 傳輸。開啟這個選項後，通訊會限制在 TCP，降低透過 UDP 連接埠探測真實路徑的可能性。適合需要面對較嚴格網路檢測的環境。
二、按場景怎麼選？
| 你的需求 | 建議模式 | 說明 |
|---|---|---|
| 最大化隱私、不需要網頁音訊與視訊 | 停用模式 | 從源頭杜絕 WebRTC 洩漏 |
| 需要 WebRTC 功能 + 保護 IP | 代理 UDP（停用 UDP） | 保留必要功能，同時阻擋 UDP 探測 |
| 日常多帳號營運、避免位址不一致 | 替換模式 | 代理 IP 與 WebRTC IP 一致，兼顧自然性與穩定性 |
| 對來源驗證很嚴格的平台 | 轉發模式 | 經 STUN 中繼，連線路徑更自然 |
一般來說，先選替換模式就能滿足大多數場景；遇到連線稽核更嚴格，或個別依賴語音功能的網站，再按需要切換到轉發或停用 UDP。
三、在哪裡設定？怎麼驗證是否生效？
設定位置: 在指紋瀏覽器中新增或編輯瀏覽器環境，進入「指紋設定」（指紋參數）區域，找到 WebRTC 選項並選擇對應模式；同時確認該環境已正確設定代理，讓流量經由預設的代理伺服器，而不是直接連到公網。
驗證方法: 設定並開啟環境後，造訪 WebRTC 洩漏檢測工具，查看顯示的 IP 是否與你為該環境設定的代理 IP 一致，以及是否露出本機真實 IP。如果顯示一致且沒有真實位址，表示設定已生效。
四、常見問題
為什麼用了代理，帳號還是可能被關聯？ 很可能是 WebRTC 洩漏。它可能繞過代理，把真實實體 IP 暴露給網站。在指紋瀏覽器中選對 WebRTC 模式，就能攔截這類洩漏。
停用模式會影響正常上網嗎？ 會影響依賴網頁音訊、視訊或語音的功能。如果確定用不到這些功能，停用模式是隱私最穩妥的選擇；需要時就改用替換或轉發模式。
總結
WebRTC 是「設定了代理仍可能洩漏真實 IP」的常見原因。指紋瀏覽器提供的 替換、轉發、真實、停用、代理 UDP 五種模式，本質上是在「隱私保護」與「功能可用」之間取捨：預設先用替換，稽核嚴格時用轉發，不依賴音訊/視訊就停用，必要時再關閉 UDP。選好後用洩漏檢測工具驗證，確認顯示的 IP 與代理 IP 一致，才算真正設定完成。
