瀏覽器代理擴充功能最容易踩的坑是作用範圍：它只接管瀏覽器流量，還可能因為規則沒對上而走直連。文章依用途為擴充功能分類，列出協定、認證、權限、維護狀態等評估面向，並給出查出口 IP 與 WebRTC 外洩的自我檢測步驟。
瀏覽器代理擴充功能有個常被忽略的邊界：它只接管瀏覽器發出的請求。系統更新、桌面用戶端、其他 App 的流量照樣走原本的路。先想清楚要代理的究竟是什麼，再挑工具，能省掉後面很多排查。
先依用途分三類
最常見的需求是單一站點切換：讓某幾個網域走代理，其餘照舊直連。這類情境靠規則表控制，擴充功能的價值在於切換快、能依網域分流。
第二類是全域代理，瀏覽器裡所有流量都從同一個出口出去。設定最簡單，但代價也很直接：出口掛了，瀏覽器等於斷網，日常使用體驗不穩。
第三類和環境綁定，每個瀏覽器設定檔固定一個出口，設定檔之間互不影響。多帳號或多專案並行時用的是這類思路，擴充功能在這裡更多是補充，出口本身通常在更底層設定。
評估一個擴充功能看這幾項
協定支援排第一。HTTP、HTTPS 代理只處理 TCP，SOCKS5 更通用一些，但對 UDP 的支援取決於實作，很多擴充功能把 UDP 直接放行或直接丟掉。這點後面會提到，它和 WebRTC 是否外洩直接相關。
認證方式要看清楚。使用者名稱密碼認證方便，但擴充功能裡保存的憑證是本機明文或弱加密，電腦被別人使用時容易被讀到；IP 白名單認證不需要在擴充功能裡存東西，代價是換網路就得重新加白名單。
作用範圍是最容易出問題的地方。規則模式下，沒對上任何規則的網域預設走直連，而你未必知道哪些網域是頁面實際在請求的。HTTPS 站點在建立連線後，擴充功能只能看到網域，看不到具體路徑，所以依路徑分流的想法基本上行不通。
權限範圍也要看一眼。一個代理擴充功能如果同時申請了讀取所有網站資料、分頁資訊、剪貼簿之類的權限，就要問一句這些權限和它宣稱的功能有沒有關係。瀏覽器擴充功能的資訊清單版本升級也在收緊可用介面，一些老擴充功能因此被迫改架構。
維護活躍度不用看更新日誌多不多，看的是有沒有人在跟進上游變化。代理類擴充功能裡，Proxy SwitchyOmega 的商店版本已經下架，社群裡維護的分支（例如 ZeroOmega 這一路）接手了後續調適；FoxyProxy 一類的擴充功能在多瀏覽器上都有版本。這些只作中性舉例，具體哪個更合適還是取決於上面幾項。
它蓋不住的那些流量
擴充功能裝好之後，瀏覽器自己走了代理，但同一台電腦上的其他程式、背景更新服務，以及瀏覽器內部某些不遵守擴充功能設定請求路徑的流量，可能仍然是本機出口。檢查網路一致性不能只盯著擴充功能面板。要做完整隔離，得在系統代理或更上層解決。
自我檢測：先查出口，再查外洩
第一步查出口 IP。打開幾個會回傳訪客 IP 和所在地的頁面，一般視窗和規則命中的分頁各查一次，看結果是否一致。如果規則裡寫了代理、查出來還是本機位址，代表規則沒生效或網域沒對上。多查幾個站，能發現只讓部分請求走代理的情況。
第二步查 WebRTC。有專門的檢測頁會列出瀏覽器拿到的本機候選位址和公網候選位址，如果公網候選裡出現的是真實 IP 而不是代理出口，代表 UDP 這條路沒走代理，網頁指令碼仍然能拿到你實際的網路位置。
第三步查 DNS。網域解析的伺服器所在地和出口所在地差得太遠，某些站點會據此判斷環境異常。
最後一步是無痕視窗再測一遍。不少擴充功能預設不在無痕模式生效，需要在擴充功能設定裡手動允許，忘了這一步會得出完全錯誤的結論。
測完再決定怎麼用
自我檢測結果比擴充功能的說明更可靠。真實出口、DNS 解析位置、WebRTC 曝露情況這三項對齊以後，再決定是繼續用擴充功能，還是把出口下沉到更底層。多環境並行的情境裡，每個環境最好各配一套獨立的出口，並且固定下來，不要多台機器共用一個出口。
