Clash 開代理後瀏覽器仍洩漏真實 IP？關閉 WebRTC 與驗證步驟

為什麼開了代理仍像「看得到本機 IP」

多數使用者是以瀏覽器代理或系統代理指向 Clash，並搭配 TUN 模式 讓未尊重代理設定的程式也進同一套路由。當測速站或「IP 檢測」網頁仍列出你住家／公司出口、或網卡上的區網位址，直覺會是「規則沒吃到」。但在排除節點故障之前，有一類現象與一般 HTTP／HTTPS 代理語意不同：WebRTC 為了建立即時通訊，會做 ICE 候選採集，可能對外揭露本機可路由的位址，不一定跟著你以為的那條代理路徑走。

因此本文的定位很清楚：它不是在重複「Fake-IP、IPv6」這條線的完整教學（那是 IPv6 雙棧與 DNS 與 Fake-IP 與區網 擅長的主題），而是補上瀏覽器真實 IP顯示常見缺口——WebRTC 洩漏——以及如何用最小改動先驗證，再回頭對齊 Clash 的分流驗證與日誌。

WebRTC 是什麼？為何常繞過瀏覽器代理

WebRTC（Web Real-Time Communication）讓網頁能做視訊、語音、P2P 資料通道。建立連線前，瀏覽器通常要蒐集一批「連得到我」的候選位址：公網 IP、區網 IP、中繼位址等，並透過訊號通道交換給對端。這條路徑與「把 HTTPS 請求送進 SOCKS／HTTP 代理」不是同一件事；許多測試頁正是利用 WebRTC 相關 API，讓你看到與網頁主要載入流量不同的 IP 敘事。

換句話說，即使一般網頁瀏覽已走代理，WebRTC 仍可能呈現真實 IP資訊給具備相應腳本的頁面。這不等於「Clash 壞了」，而是瀏覽器代理語意沒有涵蓋整段 WebRTC 行為的典型情境。接下來先快速與其他「看起來在洩 IP」的原因區隔，再談關閉與驗證。

先排除：IPv6、DNS、Fake-IP 與測試站顯示項

在做 WebRTC 對照前，建議先排掉同一個症狀、不同根因的幾件事，否則會反覆改規則卻無感。若你見到的是電信商 IPv6、或雙棧下同時有 A／AAAA 造成路徑分叉，請優先依 Clash IPv6 雙棧 收斂介面與規則。若你懷疑DNS 敘事與 fake-ip、嗅探或區網閘道打架，請對齊 Clash Meta DNS，並在需要時讀 Fake-IP 與路由器，避免把顯示欄位誤判成「代理失敗」。

同時請確認你閱讀測試站時，分清它顯示的是DNS 查詢來源、HTTP 出口、還是WebRTC／ICE相關欄位；許多頁面把多類資訊並列，截圖時若只取其中一格，容易在社群討論裡被誤導成另一種故障。若你不確定目前客戶端是純系統代理、或已啟用 TUN、是否分應用分流，可先對照 如何選擇 Clash 客戶端，再把測試方法固定下來。

瀏覽器關閉或限制 WebRTC（步驟）

以下為常見桌面瀏覽器的思路與路徑；實際選單文字會隨版本更新，請以你裝置上可見為準。目標只有一個：讓網頁無法透過 WebRTC 取得可辨識你網路身份的候選位址，或至少降到可接受的風險。

• Google Chrome／Microsoft Edge（Chromium）：可在位址列開啟 chrome://flags 或 edge://flags，搜尋與 WebRTC 相關項目（不同版本命名略異），把高度可能讓 WebRTC 暴露本機或區網路徑的實驗選項改為停用或較保守的一方；變更後通常需要重新啟動瀏覽器。另可檢查是否安裝了會改寫 WebRTC 的外掛，避免彼此打架。
• Mozilla Firefox：於 about:config 搜尋 media.peerconnection.enabled，將其設為 false 可全面停用 WebRTC（副作用：依賴 WebRTC 的網站服務可能不可用）。若你希望保留功能但降低洩漏，亦可搜尋 media.peerconnection.ice.default_address_only、media.peerconnection.ice.no_host 等鍵值，逐步收緊候選範圍；不同版本鍵名可能調整，請以你版本文件為準。
• Safari（macOS）：Safari 對 WebRTC 與站點權限的管理與 Chromium／Firefox 不同，請在「開發」或隱私相關設定中確認是否允許網站取用相機／麥克風／即時通訊，並以實際頁面測試為準；系統層亦可能有「限定只使用代理」類的限制，但無法在此替代官方文件逐版對照。

若你不想動實驗旗標，只想在特定情境處理，優先選擇只用來做敏感測試的乾淨設定檔（Chrome 使用者檔案／Firefox profile），把關閉 WebRTC 的策略只套在該檔，避免日常視訊會議被波及。

只想改瀏覽器：擴充功能與風險取捨

市面上有不少宣稱可「阻擋 WebRTC 洩漏」的瀏覽器擴充套件。它們的本質多為改寫候選採集、遮蔽區網位址或限制 host candidate。好處是最小改動、可隨開隨關；壞處是你把網路行為信任給第三方程式，必須檢視權限範圍與是否開源、是否長期維護。對高度敏感需求，優先仍以瀏覽器內建設定或可信的原廠策略為主，擴充當輔助。

另一條路是容器化：用獨立瀏覽器或獨立設定檔專門跑測試站，並在系統層搭配 TUN 讓進程路徑一致；這能避免「同一個瀏覽器裡外掛互相覆寫」的不可預期性。

與 Clash 搭配：系統代理、TUN 與分流驗證

Clash 能做的是把可走規則引擎的那一段流量納進你的策略：不論你是 SYSTEM PROXY、手動 PAC、還是 TUN 接管。若你希望「驗證規則是否真的讓某網域走某策略組」，請在變更後於客戶端觀察連線日誌：主機名、命中規則、策略組與實際連線結果是否一致；撰寫與排序可對照 規則分流最佳實踐，避免一條過寬規則長期遮擋細粒度條目。

需要強調：關閉瀏覽器 WebRTC常是「最低摩擦」的解法；只靠加規則但不改瀏覽器，未必能阻止網頁端 JavaScript 取得 ICE 敘事。若你調整 TUN、改路由後出現無法連線、DNS 怪象，請依 關閉代理後無網路與 TUN 清理 清殘留設定，避免把路由問題誤判成 WebRTC。

rules:
  - DOMAIN-KEYWORD,stun,DIRECT
  - DOMAIN-SUFFIX,your-test-site.example,PROXY
  - MATCH,DIRECT
  # Names are examples only: align STUN/TURN with your threat model.

如何用測試站對照「還會不會洩」

建議固定使用兩個以上來源的測試頁，並在每次測試前記錄：（1）Clash 模式（Rule／Global 等）、（2）是否 TUN、（3）瀏覽器是否關閉 WebRTC、（4）是否暫停 DoH。對照步驟：先baseline（僅開代理但未關 WebRTC）截圖，再關閉 WebRTC 後刷新，確認WebRTC 欄位是否消失或改為符合預期的敘事。

若你關閉 WebRTC 後，HTTP 出口 IP與DNS 敘事仍與預期不符，再回到 Meta DNS、IPv6 與 Fake-IP 的專文路徑收斂，而不是在 WebRTC 上一直繞圈。

常見誤判與除錯順序

1. 把 WebRTC 顯示當一般 HTTP 代理失敗：兩者層級不同；先做瀏覽器關閉／限制再談規則。
2. 把區網 IP 當「沒代理」：ICE 候選本就可能含區網位址；重點是你是否還能從頁面推出你的公網出口。
3. 忽略 IPv6 分叉：請與 IPv6 雙棧 對照，先確認是不是 IPv6 直行。
4. 多工具同時駐留：VPN、公司代理、其他過濾軟體與 Clash 疊加時，路由優先級難以直覺預測；建議暫時縮到單一方案對照。

自檢清單

1. 測試頁顯示的究竟是 DNS、HTTP 出口、還是 WebRTC／ICE？是否已分欄對照？
2. Chrome／Edge／Firefox／Safari 是否已完成關閉或限制 WebRTC 的最小改動？
3. IPv6、Fake-IP、DoH 是否已依專文路徑逐一排除混淆？
4. Clash 是否使用預期模式與 TUN？連線日誌是否看得到對應主機名與策略組命中？
5. 規則順序是否過寬？是否已參考 規則分流最佳實踐 檢查？
6. 調整路由後若斷網，是否依 TUN 清理流程 復原測試？

結語

「已開 瀏覽器代理或 TUN，測速站卻仍像看得到真實 IP」這類問題，常把 WebRTC 洩漏與代理／分流驗證混在同一個情緒裡。把瀏覽器端的 WebRTC 先收斂，再用 Clash 日誌核對規則命中，你能快速分辨：究竟是ICE 層敘事，還是 DNS／IPv6／Fake-IP 的另一條線——兩件事都值得修，但順序錯了會永遠覺得「代理沒用」。

相較把一切推給節點品質，願意在瀏覽器與核心設定之間建立固定可重現的測試節奏，長期回報是：當網站改版測試頁、瀏覽器升級 WebRTC 行為，你仍能用同一套清單定位，而不是每次重裝碰運氣。

→ 立即免費下載 Clash，開啟流暢上網新體驗，用可核對的連線日誌與清楚的分流規則，把瀏覽器與系統層的行為放在同一張除錯圖裡。