先釐清：像「沒走代理」的幾種長相

實務上最常碰到的抱怨有三類。 第一，頁面能開，但出口 IP 仍是自家頻寬，或只有少數網域不走節點；第二，HTTPS 正常、但某些追蹤／廣告網域像繞過分流，其實是解析路徑沒進 Clash；第三，系統已設好代理，Firefox 卻堅持手動的 SOCKS／HTTP 主機，與 Clash 圖殼顯示完全對不起來。 若你正在選擇由哪種客戶端統一管理規則，可先讀 如何選擇適合自己的 Clash 客戶端， 再回來對照 Firefox 這一側——多數人會希望Clash 當唯一分流腦，瀏覽器只負責跟隨作業系統。

和 Chromium 系相比，Firefox 對自家 DNS 解析堆疊與進階偏好更敏感；因此「Chrome OK、Firefox 怪」是合理現象，並不一定代表 Clash 沒開。 想先複習系統層怎麼接手流量，可併讀 TUN 模式深度解析， 區分「封包進了核心」與「瀏覽器仍用另一套 DNS／代理語意」。

為什麼只有 Firefox 特別「不聽」系統設定？

Firefox 會在三個層次覆寫或補充你在作業系統裡設好的代理。 第一是圖形介面中的手動代理／自動設定網址，優先權常常高於「跟隨系統」；第二是 DNS over HTTPS：一旦啟用，部分查詢會經由瀏覽器挑選的 HTTPS DNS，與你在 Clash 設的 nameserver、fake-ip 路徑脫鉤，看起來就像「DNS 仍直連」或規則對不上。 若要對齊 Clash Meta 的 DNS 段落與 fallback 語意，可參考 Clash Meta DNS：nameserver、fallback 與 fake-ip-filter， 避免只有瀏覽器在用另一套解析。

第三是 about:config 裡大量以 network.proxy. 開頭的偏好值：歷史版本、同步帳號、或早期測試留下的鍵，可能讓 UI 顯示「使用系統設定」但底層仍是手動 SOCKS。 另外在 macOS 上若還要同時開 TUN，也建議一併核對 macOS TUN 與系統代理衝突排查， 以免誤判成純瀏覽器問題。

步驟一：關閉或改為「預設」的 DoH（TRR）

請開啟 Firefox「設定」→「一般」→捲到網路設定下方的 DNS over HTTPS 區塊（各版本用語可能寫「啟用 DNS over HTTPS」）。 建議優先改成關閉，或選只在備援解析器失敗時（若你的版本有細分），讓解析盡可能回到系統／Clash 的堆疊。

進階使用者可開 about:config，搜尋 network.trr.mode：常見對照是 0 關閉 TRR、2 為優先 TRR、3 僅用 TRR。 排查期請先明確關閉，確認問題消失後再決定是否要用較溫和的備援模式。 若懷疑尚有 IPv6 與雙線造成的「假直連」，可並讀 IPv6 雙棧與 DNS 直連排查。

步驟二：設定畫面把代理交回系統

同一個「設定」→「一般」→「網路設定」對話框，點設定。 請選使用系統 Proxy 設定（或舊版中的「使用系統代理設定」），避免選「手動設定 Proxy」卻又填入本機位址，造成與 Clash 圖殼上的系統代理兩套敘述並存。

若你曾貼上 自動 Proxy 設定網址（PAC），測試完請清空，否則 PAC 規則可能蓋過系統代理。 改完後完全結束 Firefox 行程再重開（勿只關視窗），讓新的代理狀態整組載入。

步驟三：about:config 清理 network.proxy 與進階鍵

在位址列輸入 about:config，接受風險提示後，於搜尋框輸入 network.proxy。 重點欄位如下（實際顯示會隨版本增減，請以你機器為準）：

另可搜尋 network.proxy.allow_hijacking_localhost 等與本機相關的實驗性鍵；若你不確定曾調過什麼，可在備份設定檔後，用重新整理／還原該鍵為預設，再逐項恢復。

Typing about:config filter: network.proxy 
network.proxy.type → 5   (use system proxy settings, verify with your Firefox build)
network.trr.mode → 0     (disable DoH while testing)

步驟四：連線偵測、captive portal 與 DNS 仍直連的錯覺

Firefox 會做連線能力偵測與受限入口網路（captive portal）探測；在特定網路環境下，這些小請求若看起來「繞過」你預期的策略組，容易讓人誤以為整體沒走代理。 實務上你若已在 Clash 規則裡放行或直連這類探測網域，外觀就會像 DNS 仍本地化——此時應回到連線紀錄對主機名與策略命中，而不是只看出站 IP。

做完瀏覽器側修整後，仍建議用客戶端日誌確認該站名的第一跳是否為預期節點；必要時暫時關閉「隱私」裡過於激進的追蹤保護只作對照測試，測完即恢復。

與 Clash 對齊：用日誌與模式選擇收尾

當 Firefox 已設為使用系統 Proxy且 DoH 關閉，接下來請在 Clash 確認現況是「僅系統代理」或「TUN 一併啟用」。 若走系統代理，請核對圖殼寫入的 HTTP／HTTPS／SOCKS 埠與訂閱規則一致；若走 TUN，則多數 TCP 已由核心攔截，此時 Firefox 仍異常的機率會明顯下降。 關閉 Clash 後若作業系統卡在手動代理，請依 退出 Clash 後清理系統代理與 TUN 殘留 復原，避免 Firefox 下一輪啟動又讀到殘值。

最後，若你關心的是媒體與 WebRTC 洩漏而非純 HTTP 代理，請與 WebRTC 驗證專文 並讀：該文處理的是另一條通道，但同樣會讓人誤以為「代理沒生效」。

ℹ 提醒：請在合規且有權限的網路與裝置上使用 Clash；若屬公司資產或受管理瀏覽器，請遵循內部資安政策。本文僅協助釐清 Firefox 內建選項與系統代理的對齊方式，不提供規避管制之指引。

結語

Firefox 與 Clash 搭配時，真正棘手的是瀏覽器自己的 DoH 與殘留的 network.proxy，而不是少裝一個外掛。 依序關閉 TRR、把網路設定交回系統、用 about:config 掃過代理相關鍵值，再回 Clash 日誌驗證主機名命中，就能把「只有 Firefox 怪怪的」縮小到可重現的幾個開關。 相較於依賴瀏覽器外掛硬指 127.0.0.1，把終態收斂在系統代理或 TUN，長期維護成本通常更低。

若你希望用圖殼穩定寫入系統代理、並在單一介面裡對照連線與規則，可優先選擇與你平台契合的 Clash 系用戶端。→ 立即免費下載 Clash，開啟流暢上網新體驗，再把 Firefox 維持在「跟隨系統、關閉 DoH」的清爽狀態即可。