一、先對齊現象：HTTP 出口與「測到的 IP」可能不是同一件事
多數使用者是透過瀏覽器一般上網流量感知「有沒有翻出去」：能開 YouTube、搜尋結果地區有變，就認定代理有效。然而許多「查 IP」網站會同時觸發多種技術：一般 HTTPS 請求走系統代理或 TUN、但頁面內嵌的腳本可能透過 WebRTC 建立點對點連線，直接向對方暴露本機在 NAT 後可被觀察到的位址資訊；另外，若頁面另外發起 DNS 查詢，而該查詢沒有經過 Clash 的 DNS 模組，你會在測試結果裡看到電信或家裡 DNS 的特徵，與代理節點所在國家不一致。
因此第一步不是急著換節點，而是分開驗證：同一個測速頁上若同時列出「瀏覽器 IP」「WebRTC」「DNS」三欄，請逐欄對照哪一欄仍顯示本地資訊。若只有 WebRTC 或 DNS 欄異常，問題就不在「HTTP 代理沒開」，而在額外通道沒有被收進代理堆疊。這與我們在 fake-ip 與 DNS 排障 一文強調的觀念一致：要先釐清解析與連線是否走同一條邏輯鏈，再談規則怎麼寫。
二、WebRTC：為何會繞過傳統 HTTP 代理
WebRTC（Web Real-Time Communication）讓瀏覽器能做視訊、語音、部分 P2P 傳輸。為了在 NAT 後找到彼此，它會使用 ICE（Interactive Connectivity Establishment），過程中可能取得本機區網 IP、公網出口候選位址等，並透過信令伺服器交換給對方。這條路徑與「把 HTTPS 交給 HTTP 代理」是不同層級的：許多代理只處理 TCP 連線上的 HTTP／HTTPS，不會自動把 WebRTC 的 UDP／STUN 行為完整納入同一策略，於是測速頁就能在「代理已開」的情況下，仍從 WebRTC 欄位拼出你的真實或電信相關資訊。
在 Clash 生態中，若你使用支援 UDP 轉發的節點且用戶端／核心正確處理相關流量，有機會讓部分 WebRTC 行為較一致地跟隨代理；但實務上仍受瀏覽器實作、擴充功能、企業策略與節點是否允許 UDP影響。對一般使用者而言，最穩定的第一步仍是：在瀏覽器層限制 WebRTC 泄露，再回頭確認節點與規則。
三、瀏覽器端：關閉或限制 WebRTC 的實務做法
下列做法依瀏覽器與版本而異，請以你實際安裝的版本選單為準；核心目標是避免網頁腳本在未經你預期的情況下取得本地介面位址。
Chromium 系（Chrome、Edge、Brave 等）
可在設定中搜尋與 WebRTC、隱私相關的選項；部分版本提供限制非代理 UDP或將 WebRTC 行為限制在較不易泄露本機資訊的模式。若你使用 Brave 等強調隱私的瀏覽器，通常內建阻擋 WebRTC 泄露或類似開關，建議在調整 Clash 之餘一併開啟並重啟瀏覽器後複測。
Firefox
Firefox 可透過 about:config 調整與 WebRTC 相關的偏好設定（例如限制是否暴露公網介面、是否需經過代理等，實際鍵名請對照你所使用版本的說明文件）。修改後請完全關閉再開啟瀏覽器，再開測速頁，避免舊分頁沿用舊行為。
擴充功能
若你暫時無法在瀏覽器內建選項達成目標，可考慮信譽良好的WebRTC 控制類擴充功能（請從官方商店安裝並閱讀權限）。注意擴充功能可能與其他隱私外掛衝突，建議一次只改一類設定，方便回溯。
四、DNS 外洩：系統、瀏覽器 DoH 與 Clash 的關係
第二條主線是 DNS 外洩。當瀏覽器或系統沒有把 DNS 查詢交給 Clash 監聽的位址，而是直接使用電信自動派發的 DNS、路由器上的轉發、或瀏覽器內建的 DNS over HTTPS（DoH） 時，測速頁上的「DNS 伺服器」欄位就會顯示本地或電信供應商，與你選的代理節點所在地無關。這不代表 HTTP 流量完全沒走代理，而是名稱解析這一步繞開了你以為的隧道。
建議依序檢查：
- 作業系統 DNS：是否指向
127.0.0.1、Clash 用戶端顯示的本機 DNS 埠，或 TUN 模式下核心指定的位址；若仍是路由器或電信 DNS，請先改回與用戶端文件一致的設定。 - 瀏覽器安全 DNS／DoH：Chrome、Edge、Firefox 等可獨立啟用 DoH；若 DoH 供應商與 Clash 內設定的上游不一致，測試頁可能出現「解析路徑分裂」。可暫時關閉瀏覽器內建安全 DNS，讓解析回到系統堆疊，再由 Clash 統一處理，對照是否改善。
- 分流規則是否讓 DNS 查詢走代理：部分情境需讓對特定上游的查詢走隧道，避免被本地劫持；細節依你的訂閱與
nameserver-policy而定。
若你同時使用 WSL、Docker 或第二張網卡，還可能出現「Windows 走 Clash、子系統仍用另一組解析」的分裂現象，可搭配 WSL2 與 Windows DNS 排查 一文對齊命名空間與監聽位址。
五、在 Clash 內核對 DNS：fake-ip、上游與劫持
在 Mihomo／Meta 系核心中，dns 區段決定了查詢如何被處理：enhanced-mode 為 fake-ip 時，多數網域會先拿到假位址以加速連線建立，但測試「DNS 外洩」的網站可能以特殊方式探測，結果解讀需謹慎——若你發現只有少數站異常，請仍優先參考 fake-ip-filter 與 DNS 的補清單與對照實驗，而不是直接把問題歸因於「WebRTC」。
實務上建議確認：
dns.enable是否為true，且用戶端未關閉「接管本機 DNS」之類選項（名稱依用戶端而異）。- nameserver 與 fallback 是否可連線、是否被目前網路環境攔截；企業網或公共 Wi‑Fi 常會干擾 DoH 網域。
- fake-ip-filter 是否涵蓋內網、區域服務與已知需真實解析的網域，避免解析鏈與規則互相矛盾。
# DNS 區段示意（欄位名稱請以你所用核心文件為準）
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.example/dns-query
fallback:
- tls://dns.example:853
fake-ip-filter:
- "*.lan"
- "*.local"修改後請重新載入設定或重啟核心，再以無痕視窗開啟測速頁，避免舊連線快取干擾判讀。
六、規則與測速站：確認測試頁本身有走代理
另一種常見誤解是：規則把「測速站網域」標成 DIRECT 或誤命中 GEOIP,CN，導致你以為「全機走代理」，但測 IP 的請求其實從本地出口直連，畫面上當然仍是家裡或電信 IP。請在 Clash 日誌或連線預覽中確認該測速主機名稱實際命中哪一條規則、走哪個策略群組。
若你希望境內網站維持直連、境外網站走代理，請一併檢查 規則順序與 GeoIP 資料是否過期，必要時參考 繞過中國大陸與 DIRECT 規則 一文調整，避免「測速站被誤判為國內直連」。
| 你在測速頁看到的現象 | 建議優先檢查 |
|---|---|
| 僅 WebRTC 欄位像本地 | 瀏覽器 WebRTC 設定、UDP／擴充功能；節點是否支援所需 UDP 行為 |
| DNS 欄位顯示電信／路由器 | 系統 DNS、瀏覽器 DoH、Clash DNS 是否接管；是否被劫持 |
| HTTP(S) IP 仍像本地 | 該測速網域是否誤走 DIRECT；系統代理是否套用至該瀏覽器；TUN 是否排除該行程 |
七、IPv6、雙重 NAT 與其他邊界情況
若你的網路環境啟用 IPv6，而代理規則或節點對 IPv6 支援不完整，部分連線可能繞過預期的 IPv4 代理隧道，從測試頁看起來像「泄露」。可暫時在路由器或系統層只使用 IPv4 做對照實驗，或在 Clash 中依文件啟用相符的 IPv6 與規則選項後再測。
另外，多層 NAT、電信級 CGNAT、公司 SSL 檢查閘道都可能讓「出口 IP」與你想像的不同；這些屬於網路架構問題，未必能僅靠更換一個訂閱節點解決。若你已確認 WebRTC 與 DNS 皆已收斂，仍對特定網站 IP 顯示有疑慮，請再比對同一時間在命令列執行 curl 透過代理抓取公開 IP 服務的結果，與瀏覽器是否一致。
八、小結
Clash 顯示已連線只代表核心與用戶端整體在運作；瀏覽器 IP 檢測卻可能同時觸發 WebRTC、DNS 與一般 HTTPS，三者任一繞過代理堆疊，都會讓你覺得「像沒開」。依序處理WebRTC 泄露、DNS／DoH 是否經過 Clash、再核對規則是否讓測速站誤直連，通常就能與「節點壞了」這類直覺式結論脫鉤，把時間花在真正該改的設定上。
長期維護上，建議把「曾調整過的瀏覽器選項、fake-ip-filter 補條、以及 nameserver 變更原因」簡短記錄在筆記裡，升級用戶端或匯入新訂閱時比較不會一夜回到混淆狀態。需要從頭整理設定結構時，可先閱讀 本站設定文件，再依本文逐步核對 DNS 與規則區段。
相比僅依賴單一測速頁截圖，Clash 在規則分流、DNS 模組與多模式協同上的可調空間更大；把 WebRTC 與 DNS 兩條線索理順之後，日常瀏覽與開發工具鏈的體驗會穩定許多。