一、Firefox 為何總是跟 Chromium「不同步」

在Microsoft Windows 或 macOS 上開啟「使用系統代理設定」對多數程式有效，但 Mozilla Firefox 長期沿用自己的連線組態：可在「不使用代理」「手動」「PAC」「使用系統代理」之間切換；甚至部分版本將網路基礎結構設定託管在獨立 Firefox 設定檔內，與作業系統的網際網路代理面板並非永遠 1：1。換句話說，你在 Clash 圖形介面按下「設定系統代理」後，Firefox 若在 UI 仍是「不要使用代理」，就會繼續直連或被其他選項劫持。

另一頭，TUN（虛擬網卡通路）在系統路由層面把許多程序的 TCP／UDP「收進來」再走核心；理論上行為接近透明，但若 Firefox 將特定流量標成區域流量，或規則與 DNS 順序使你看到「規則沒套上」的假陽性（例如：DoH繞過本機dig），仍需要先釐清是應用層問題還是規則與 DNS／fake-ip問題。一般排查可搭配站內《Clash 常見報錯與排除》對照規則與連線紀錄。

二、對齊 Clash：監聽位址、SOCKS5 與混合埠

在碰 Firefox 的任何選項前，請先在客戶端確認Socks-port／mixed-port實際數字（常見7890、7891不等），以及是否僅繫結127.0.0.1。Clash SOCKS5 端點在 Firefox 連線設定中應寫成：127.0.0.1／埠號／類型 SOCKS5。不要把「HTTP／HTTPS／SOCKS 四欄都用同一號」後卻協定類型選錯——例如僅對 HTTP 填入代理伺服器地址，而真正希望走代理的是HTTPS 主流程，Firefox 對「僅 SOCKS 走代理、HTTPS 留白」這類組態非常敏感。

若你使用混合埠對外提供http://127.0.0.1:<mixed>這類進入點，請在 Firefox 裡對應成手動設定下的 HTTP 或將 SOCKS 指向同一數字並勾選對應轉發語意—以客戶端說明為準。Mihomo／Clash側若顯示某埠「合併」，通常代表該監聽可同時處理 CONNECT 請求。

三、開了 TUN，Firefox 還要設定嗎

TUN 模式讓許多程式無需HTTPS_PROXY也能被核心接管；對瀏覽器而言經常可以不用在 Firefox UI 再添一層手動 SOCKS，但若你希望對照實驗（例如只用瀏覽器走 SOCKS、其餘系統走規則），仍可能需在 Firefox停用系統級透明效果與manual並存以免重複標記。DEST-PORT與規則命中要以客戶端連線紀錄為準；若對 TUN／Meta 載入順序不熟，可先讀《Clash TUN 模式開啟方法》對照環境準備項目。

邊界情境：你已開 UWP／Store 應的 loopback（站內另文），但 Firefox並非該問題的主要族群；本篇焦點仍放在Firefox 自己的代理設定／DoH／套件。

四、設定 → 一般 → 連線設定：先選對「來源」

  1. 不要使用代理：明確直連，系統代理與 Clash 都不會接手（除非 TUN 已全面接管且你未再疊手動層）。
  2. 自動偵測此網路的代理設定：依賴 WPAD／環境，易與企業網或殘留 PAC 衝突。
  3. 使用系統代理設定：此時才與 Clash「寫入系統代理」一致；若系統層沒有有效 PAC／代理，Firefox 行為會像直連。
  4. 手動設定：輸入 HTTP／HTTPS／SOCKS 主機與埠；需與 Clash 實際監聽逐位一致。

常見錯誤：以為「系統已代理」就萬無一失，但 Firefox 仍停在「手動」且填了錯誤埠；或反過來想走SOCKS5卻在 UI 只填了「HTTP 代理」欄位而SOCKS 主機留空。

五、about:config 與 network.proxy 系列

在網址列輸入about:config接受風險提示後，以下項與Firefox 代理設定高度相關（實際鍵名隨版本微調，請以畫面搜尋為準）：

  • network.proxy.type：整體代理模式（常見0無、1手動、2為 PAC／自動設定檔，以及使用系統代理設定等），須與「連線設定」畫面一致。
  • network.proxy.socks／network.proxy.socks_port：SOCKS 主機與埠；搭配network.proxy.socks_version確認第 5 版。
  • network.proxy.share_proxy_settings：是否多種協定共用同一組位址（依需求開關）。
  • network.proxy.no_proxies_on：略過清單；若寫太寬，目標網域會被排除而看似直連。

若你曾用企業政策或延伸功能鎖定代理，可能出現「UI 看起來可改、重啟又還原」的情況，此時要往政策檔與套件權限查，而不是只改一次 UI。

六、DoH 與 Clash DNS：別讓「解析」躲過規則

Firefox 內建 DNS over HTTPS（設定 → 隱私權與安全性 → 阻斷追蹤元件下的 DNS）若指向公共解析商，可能繞過你在 Clash 設定的本機 DNS或fake-ip策略，讓「目的地主機名」在核心看起來與瀏覽器實際連線不一致，進而誤判為規則沒命中或節點顯示錯位。排查時可暫時關閉 DoH、改由系統 DNS 或改指向與核心一致的解析路徑，再重新整理頁面觀察連線紀錄。

若你同時啟用阻斷追蹤內的嚴格模式，少數站台的跨網域資源可能與代理路徑互動異常，建議以標準先交叉比對。

七、擴充功能與「第二套代理」

像是 SwitchyOmega 類工具會在瀏覽器內再建一層情境與 PAC；若未指向127.0.0.1正確埠，或與 Clash 的系統代理雙重改寫，Firefox 可能只走套件指定的舊節點，看起來像「Clash 沒反應」。處理方式通常是停用套件或把套件代理目標與 Clash 本機埠對齊，再重新測試。

八、實測驗證順序（建議照表勾）

  1. 客戶端：混合埠／SOCKS 埠監聽中，規則與日誌可開。
  2. Firefox：連線設定與network.proxy.type一致；手動模式位址／埠無誤。
  3. 關閉或對齊 DoH；必要時改 DNS 與核心策略一致。
  4. 停用可能改寫代理的擴充功能後重試。
  5. 以出口 IP 查詢頁（僅作參考）搭配核心連線目的地交叉比對。

若需從終端機對照同一台機器的環境變數路徑，可延伸閱讀站內《Mac 終端機與 Clash 代理》（流程與瀏覽器 UI 不同，但「誰在什麼層套代理」的思維相通）。

九、小結

Firefox 與 Chromium 分屬兩套網路堆疊；在已跑 Clash 的前提下，請把代理未生效拆成「本地埠與協定是否對齊」「Firefox 代理設定是否與系統代理／手動 SOCKS5一致」「about:config是否被政策或舊值鎖住」「DoH是否讓 DNS 與規則脫鉤」「擴充功能是否蓋掉本機代理」五段，逐段消去。相較於零散文，以開源核心自行維護規則與日誌，長期可控性通常更好；圖形客戶端也能降低改檔頻率。若尚未完成訂閱匯入與基礎啟動，可先依《Clash Verge Rev 設定教學》把環境跑通，再回頭對照本文逐項檢查。→ 立即免費下載 Clash，開啟流暢上網新體驗