先把現象分桶：你遇到的是哪一種？
在進入六步之前，建議用兩分鐘把症狀歸類，避免把「DNS 問題」當成「代理沒開」，或把「僅 SOCKS5」當成「系統代理已就緒」。
第一種：Chrome 能上外站，Firefox 完全像沒開 Clash。這類多半與 Firefox 未讀取系統代理、或仍停留在手動／不代理有關，優先檢查 Firefox「設定 → 一般 → 網路設定」與 about:config 中的 network.proxy.type。
第二種：兩個瀏覽器都能上，但 Firefox 只有特定網站失敗。常見於 DNS over HTTPS（DoH）、廣告攔截、或規則把該網域送到不支援的節點；此時應交叉比對 Clash 連線日誌與 Firefox 網路面板。
第三種：一開 TUN，Firefox 與其他程式一起斷線。這偏向整機路由或 DNS 模式問題，請先參考本站Clash TUN 與系統代理總覽關閉 TUN 恢復連線後，再回來對照本文的瀏覽器層設定。
| 觀察現象 | 較可能主因 | 建議先查 |
|---|---|---|
| 僅 Firefox 像直連 | 瀏覽器代理模式非「系統」、或被手動值覆寫 | 步驟二、三 |
| Firefox 顯示代理錯誤但 Chrome 正常 | 手動 SOCKS／HTTP 埠填錯、或僅開單一協定埠 | 步驟二、四 |
| 開 TUN 後多數程式正常、Firefox 少數網域失敗 | DoH、擴充套件、或規則命中 DIRECT／REJECT | 步驟三、五、六 |
步驟一：在 Clash 端寫清「系統代理」與「TUN」各自是否開啟
Firefox 所謂的「使用系統代理設定」，讀的是作業系統寫入的代理欄位，而不是 Clash 視窗上你「感覺有開」的抽象狀態。實務上請在客戶端確認兩件事：
第一，系統代理開關是否真的為開。多數基於 Clash Meta（mihomo）的 GUI 會把「系統代理」與「TUN」分開顯示。若你打算讓 Firefox 走「系統代理」路徑，請在開啟 Firefox 前確認該開關已啟用，並在 Windows「設定 → 網路和網際網路 → 代理」或 macOS「系統設定 → 網路 → 詳細資訊 → 代理」中，看得到本機位址與埠號（常見為 127.0.0.1 搭配混合埠）。
第二，若你打算主要依賴 TUN，仍建議保留一輪對照實驗。先只開系統代理、關閉 TUN，確認 Firefox 在「使用系統代理設定」下可連線；再只開 TUN、暫時關閉系統代理，觀察 Firefox 是否改由虛擬網卡路徑恢復。這能立刻分辨問題在「OS 代理欄位」還是「TUN／DNS／規則」。
若你希望規則層行為更透明，可搭配閱讀YAML 規則與策略組教學，用連線日誌確認 Firefox 發出的請求實際命中哪一條規則，而不是憑感覺切換開關。
步驟二：檢查 Firefox 圖形介面的「網路設定」優先順序
路徑為：設定 → 一般 → 捲動至「網路設定」→ 設定…。此處決定了 Firefox 對外連線時，要不要讀取系統代理、或改用手動 HTTP／SOCKS。
選項「使用系統代理設定」：對應 about:config 中通常會看到 network.proxy.type 為 5（依版本可能略有差異，以實機為準）。若你選了這項却仍像直連，回到步驟一確認 OS 欄位是否真的寫入；部分企業環境會用群組原則鎖定代理，導致 Clash 寫入失敗。
選項「手動設定代理」：當 Clash 只提供 SOCKS5、或 HTTP 與 SOCKS 監聽在不同埠時，Firefox 必須分欄位填對協定與埠。常見錯誤是只在「HTTP 代理」填了埠、卻沒勾選或沒填 SOCKS，結果仍嘗試以不符合 Clash 監聽方式發連線。若你的客戶端使用混合埠（單一埠同時支援 HTTP 與 SOCKS），則可在手動模式將 HTTP 與 SOCKS 皆指向同一本機埠，以降低設定錯誤率。
選項「不使用代理」：若曾為除錯改過，之後忘記還原，就會出現「Clash 明明開著，Firefox 永遠直連」的假象。請在改動後完全結束 Firefox 行程再重開，避免舊設定被快取在工作階段中。
步驟三：用 about:config 對齊底層鍵值與 SOCKS DNS
在網址列輸入 about:config，接受風險提示後，用搜尋列篩選下列鍵值。這一步專門處理「圖形介面看起來正確，實際行為卻不一致」的落差。
network.proxy.type：整數型別，控制 Firefox 代理模式。若你打算完全交給系統，請確認未被其他擴充套件或企業政策改成手動或關閉。若你改以手動 SOCKS 測試，通常會對應到手動模式。
network.proxy.socks／network.proxy.socks_port：手動 SOCKS 時應指向 127.0.0.1（或 Clash 顯示的本機位址）與正確埠號。埠號錯一位，症狀就會像「永遠連線中」。建議與客戶端主介面顯示的埠逐字比對。
network.proxy.socks_remote_dns：設為 true 時，DNS 查詢會嘗試經由 SOCKS 通道送出，對「只有 IP 通、網域永遠解析失敗」類問題特別關鍵。若你使用手動 SOCKS 卻未開啟此項，可能出現部分網站能上、部分永遠打不開的割裂感。
network.proxy.share_proxy_settings：若你希望所有通訊協定共用同一組代理設定，可視需求調整；錯誤組合時可能讓 HTTPS 與 HTTP 走不同路徑，排查時容易誤判。
修改 about:config 後，建議清一次 DNS 快取並重啟 Firefox：在網址列開啟 about:networking#dns，使用「清除 DNS 快取」按鈕（若版本提供），再回到測試頁。若你同時啟用 TUN 與 fake-ip 類 DNS 模式，也可一併參考Fake-IP 與 Redir-Host 選擇與本地解析，避免把解析問題誤判成瀏覽器代理失效。
步驟四：釐清「僅 SOCKS5」與「系統代理寫入 HTTP」是否打架
Clash Meta 系客戶端常同時提供系統代理（多為 HTTP／HTTPS 指向混合埠）與本機 SOCKS5。Firefox 允許你走任一條路，但不要混用兩套彼此矛盾的設定：例如在圖形介面選「系統代理」，卻又在 about:config 留著指向舊埠的手動 SOCKS，可能導致實際連線行為與預期不符。
建議的實驗順序是：先統一走系統代理（Clash 開系統代理、Firefox 選系統、確認 OS 欄位正確）→ 若仍失敗，再改為純手動 SOCKS（暫時關閉系統代理開關以避免雙寫）→ 最後才疊加 TUN。每一步只做一個變因，並用同一個測試網頁驗證，會比一次開四個開關更容易找到斷點。
若你使用僅暴露 SOCKS、未暴露 HTTP 的特殊配置，請記得：Chrome 在部分平台會透過系統代理讀 HTTP，而 Firefox 手動 SOCKS 則要求你明確勾選 SOCKS 版本（v5）並填對埠。兩者「看起來都是開 Clash」，實際生效的卻是完全不同的堆疊。
步驟五：啟用 Clash TUN 後，用兩個快速實驗驗證 Firefox 路徑
當 TUN 正常時，理論上多數應用程式的 IP 流量會經由虛擬網卡進入 Clash，再依規則分流。此時 Firefox 的「系統／手動代理」反而變成第二層設定：若與 TUN 期望的路徑互相覆寫，仍可能出現少數異常。
實驗 A：無痕視窗。以 Ctrl＋Shift＋P（Windows／Linux）或對應快捷鍵開啟無痕視窗，排除一般擴充套件干擾。若無痕正常、一般視窗異常，幾乎可斷定是擴充套件或快取問題，而非 Clash 本身。
實驗 B：全新設定檔。以 firefox -ProfileManager 建立乾淨設定檔後啟動，若立刻恢復，代表舊設定檔內有殘留的代理或實驗性旗標。此時可選擇逐步匯入書籤，而非整包複製 prefs。
若 TUN 開啟後是整機無網，請不要執著於 Firefox；先回到 TUN 總覽文檢查 DNS、路由與其他 VPN 軟體衝突。Firefox 單獨異常時，再優先懷疑 DoH 與擴充套件。
步驟六：仍失敗時的進階檢查（DoH、指紋防護、UWP 邊界）
下列項目不屬於「六步內必做」，但當基礎設定都正確、症狀仍詭異時，命中率很高。
DNS over HTTPS：Firefox 內建 DoH 可能繞過你以為正在使用的「系統 DNS」，導致在 fake-ip 或公司內網環境下出現解析不一致。可在「設定 → 一般 → 網路設定」底部或「隱私權與安全性」相關區塊暫時關閉 DoH 做對照測試。
privacy.resistFingerprinting：此類進階偏好有時會改變時區、螢幕或網路相關行為的預設策略，與特定網站或 SSO 登入頁互動時，可能放大成「只有某幾站異常」。建議在複製問題時暫時還原預設值交叉驗證。
Windows 與 UWP 邊界：若你同時使用 Microsoft Store 類應用或混合環境，可參考Windows 11 UWP 回環與 Clash理解「瀏覽器正常、商店異常」與代理寫入的差異；雖然 Firefox 並非 UWP，但同一台機器上多代理並存時，常有類似的混淆感。
最後，請確認電腦日期時間正確。TLS 憑證驗證失敗時，瀏覽器常顯示成「連線逾時」或「安全連線失敗」，與代理無關卻容易被誤判為 Clash 節點壞掉。
常見問答（精簡版）
問：為什麼 Chrome「不用額外設定」就好用？答：Chromium 系瀏覽器在許多平台預設緊密讀取系統代理，而 Firefox 給使用者更高比例的手動覆寫空間；一旦曾為公司網路或測試改過，就容易遺留在非系統模式。
問：開著 TUN 還需要改 Firefox 嗎？答：多數情況下 TUN 會讓流量進入 Clash，但 Firefox 的 DoH、擴充套件與少數實驗性偏好仍可能造成「只有這個瀏覽器怪」。建議以無痕與新設定檔快速二分法定位。
問：六步都做完仍失敗怎麼辦？答：回到 Clash 日誌檢查該網域是否被規則送到 DIRECT、或節點本身 TLS 失敗；必要時先關閉 TUN 恢復上網，再單獨驗證節點與訂閱更新。
寫在最後：先把「誰在管代理」說清楚
Firefox 與 Clash 同時存在時，至少有三個「決策點」：作業系統代理欄位、Firefox 自己的代理模式，以及 Clash 是否以 TUN 在更底層轉發。把這三層的開關順序寫清楚、每次只改一個變因，就能在很短的時間內縮小範圍，而不是反覆重裝瀏覽器或重灌 Clash。
相較手動拼湊核心與驅動，一體化、已整合 Meta 核心與 TUN 流程的 Clash 客戶端，通常能讓你在圖形介面中完成訂閱匯入、系統代理與透明轉發切換，並用連線紀錄對照規則命中。若你希望把時間花在節點品質與規則優化，而不是與瀏覽器代理選項拔河，可以從本站提供的安裝包開始：
更多策略組設計、Rule Providers 與 DNS 防洩漏觀念，歡迎繼續瀏覽技術專欄；若你同時使用開發者工具鏈，也可併讀開發者場景分流教學，釐清終端機環境變數與瀏覽器代理並存時的差異。