常見現象：什麼情況像「雙代理」或環路？

你可能遇到的是：全系統其它 App 正常，只有 Chromium 類瀏覽器（Chrome、Edge、Brave 等）一直轉圈；或是境外站打開很慢，但同一台機器上終端機用 curl 測卻明顯較快；少數案例則是本機服務頁（例如開發用的 http://127.0.0.1:xxxx、路由器後台）變得怪怪的。這些都很像「流量在作業系統已被 Clash 接走，瀏覽器外掛又硬把請求塞進同一個本機代理埠」所導致的雙 HTTP 代理或重複 CONNECT，而不是單純節點到期。 若你希望先確認 Clash 在系統層到底做了什麼，可對照 TUN 模式深度解析 與 macOS 上 TUN、系統代理與延伸授權 兩篇，避免把「外掛疊加」誤判成節點或 DNS 單一問題。

為什麼 Clash 開著，瀏覽器還會出問題？

SwitchyOmega一類外掛的核心是：在瀏覽器行程內覆寫代理設定（含 PAC 情境規則）。當你在圖殼已勾選「設定系統代理」或啟用 TUN 時，作業系統層往往已把大多數 TCP 導向 Clash；此時若外掛模式仍是「把 HTTP(S) 代理設成 127.0.0.1:7890」之類，就等於瀏覽器先把請求交給本機埠、再進一次 Clash 協定堆疊。輕則延遲與重試變多，重則在錯誤的規則搭配下形成請求回到代理自身的迴圈（例如某條規則把「本機代理」又指回自己），外觀就是無法完成或極慢。 你也可以把「終端與 Docker 如何對齊 mixed-port」視為同一套埠語意練習，見 Docker 與終端走 mixed-port， 釐清誰該是唯一的「出站前最後一層」。

另一個高頻點：系統已設手動代理、PAC、TUN 三者之一在生效，外掛卻用自動切換依網域跳不同的「本機代理」，容易與 Clash 規則重複做分流決策。長期維護上，多數使用者會傾向「規則與策略組都交給 Clash」，依 規則分流最佳實踐 收斂邏輯；瀏覽器則回到單一路徑，減少兩邊規則打架。

該關哪一層？建議決策順序

若你的訴求是「整台電腦盡量由 Clash 統一分流」，那麼優先關掉或停用 SwitchyOmega 對本機代理的覆寫，讓瀏覽器遵守作業系統代理或 TUN 情境即可。只有在必須讓瀏覽器與其它 App 走不同出口時，才保留外掛；此時務必確認外掛沒有再把流量指回同一個 Clash 埠做二次包裝，並避免與 TUN 同時「各說各話」。不確定該用哪種客戶端承載規則時，可先讀 如何選擇適合自己的 Clash 客戶端， 再決定由誰當「單一真相來源」。

SwitchyOmega 實測：改直連、關閉指向本機代理

以下以常見介面描述，實際選單名稱可能隨版本略異，但邏輯一致。目標是讓外掛不要再指到本機 Clash 埠，改由系統或「直接連線」承接。

  1. 點外掛圖示 → 進入選項。
  2. 在情景模式中，若「proxy」類型裡填了 127.0.0.1 加埠號，先改為不使用代理的主機名稱清單只保留必要本地網域，或乾脆新建一個情景叫 系統代理／Follow system（若外掛有內建）。
  3. 將預設情景（或自動切換最後 fallback）設為 DIRECT 或 系統代理，不要用「本機 HTTP → 再進 Clash」那一條當全域預設。
  4. 若使用自動切換，檢查是否有規則把「所有未匹配」導向本機代理；該條應改為 DIRECT 或系統。
  5. 儲存後完全關閉瀏覽器再開，或用無痕視窗驗證，避免舊 PAC 快取殘留。

驗證「瀏覽器是否仍繞一圈本機」時，很適合一併看 WebRTC 與出口一致性，可參考 關閉 WebRTC 與瀏覽器出口驗證； 該文角度不同，但同樣強調瀏覽器側設定不要與系統代理互搶解讀權。

避免環路：127.0.0.1、mixed-port 與「代理再指代理」

代理環路的典型樣貌是日誌裡同一來源 IP對本機 listening 埠的連線數暴增、或瀏覽器開發者工具顯示請求始終落在 127.0.0.1 卻永遠完不成。根因多半是：外掛／PAC 規則「凡是 HTTPS 都走 127.0.0.1:port」，而 Clash 對該站的下一跳又觸發同規則，形成自我指涉。處理原則很簡單：只保留一個本機代理入口；若 Clash 已聽在 mixed-port，瀏覽器不要再指定第二個同名入口。 在 Windows 上使用 WSL2 時，localhost 轉發與宿主機埠還要別搞混主機側與子系統側，見 WSL2 與宿主機 Clash， 避免把「子系統代理字串」與 Windows 瀏覽器外掛混在同一套心智模型裡。

Conceptual loop (avoid): browser → 127.0.0.1:7890 → Clash → rule sends HTTPS proxy again to 127.0.0.1:7890 
Browser extension: USE HTTP proxy 127.0.0.1:7890
Clash mixed-port: LISTEN 127.0.0.1:7890
Fix: set extension to DIRECT or system proxy; single path only.

TUN／系統代理與外掛併存時的核對

TUN開啟時，理論上系統內多數應用流量已進入核心；此時瀏覽器外掛若仍強制 HTTP 代理，最常見的是效能變差而非一定立刻斷線。為了行為可預測，仍建議外掛改為 DIRECT／系統。若你同時會開關「系統代理」做測試，請在關閉 Clash 後確認 OS 沒有留下手動代理，否則外掛與系統狀態會更難查；完整清理步驟見 退出 Clash 後清理系統代理與 TUN 殘留。 如此一來，「只開 Clash／只開外掛／兩者誰當主角」才不會在每次重開機後又亂序。

ℹ 提醒：請在合規且有權限的網路環境下使用代理與分流；公司設備若禁止雙重代理或瀏覽器外掛，以內部政策為準。本文僅協助釐清技術疊加與本機排錯，不提供規避網路管制之指引。

結語

Clash 與 SwitchyOmega 同開時，多數「怪現象」來自兩層代理決策與本機 loopback 路徑重疊，而不是單純節點故障。把瀏覽器外掛改成直連或跟隨系統、讓 Clash 保持唯一出站規則中心，通常就能消掉無限轉圈與特定網域卡死。需要混合埠與環境變數對齊時，仍可依 mixed-port 與終端／Docker 專文 把本機埠號收斂到單一真實值。

若你希望用圖殼一次看清「系統代理是否寫入、TUN 是否啟用、規則由誰決策」，可先選流程清楚的 Clash 系客戶端再細調。→ 立即免費下載 Clash，開啟流暢上網新體驗，把單一路徑、可重現的代理狀態當作長期使用的前提。