一、先界定症狀：不是「Clash 壞了」，而是「哪一層沒接上」

在Windows 11／Windows 10桌面環境，典型使用者會描述：代理軟體已顯示系統代理開啟、工作列圖示正常，但開啟 Chrome 後造訪出口 IP查詢頁，結果仍像家用電路；或搜尋結果頁能開，影片分段 CDN卻異常；又或僅特定網域永遠無法套上預期的策略群組。這些都不一定要先動到節點或訂閱。

建議先把問題拆成三問：TCP／TLS主流程有沒有經過127.0.0.1上 Clash 監聽的HTTP／SOCKS或mixed-port？UDP（尤其 QUIC）是否在同一路徑？主機名稱在瀏覽器端與核心端的解析結果是否一致？三者任一為「否」，你看見的就會像「Chrome 繞過 Clash」。如需對照規則與錯誤碼語意，可並讀《Clash 常見報錯與排除》。

二、QUIC／HTTP3：為何「关了代理仍像半套」

QUIC承載的HTTP/3大量使用UDP連線。許多家庭／公司網路對 UDP 的NAT與防火牆行為與 TCP 不同；若你的 Clash 規則或模式偏重在 TCP 透明轉發，而瀏覽器仍優先協商 HTTP/3，可能出現「同一站台部分資源走 HTTP/2、部分嘗試 QUIC」的分裂路徑，外在感受便是網頁能開但不穩或看似直連。

實測上最務實的一步，是先在 Chrome 將 QUIC 關閉做對照實驗：chrome://flags搜尋Experimental QUIC protocol，設為Disabled後完全結束Chrome 行程再重開（含背景常駐）。此舉會迫使多數 Google 系站台退回 HTTP/2 over TLS（TCP），較容易與系統代理路徑對齊，也讓你在 Clash 端的連線紀錄更易讀。確認問題消失或明顯緩解後，再決定是否長期關閉，或改以TUN等方式讓 UDP 也進核心統一處理。

三、安全 DNS（Secure DNS）：別讓解析與規則「各說各話」

Chrome 內建的安全 DNS會以HTTPS／TLS向公共解析商查詢，繞過傳統意义上「系統發給網卡的最終 DNS」。若你的Mihomo／Clash DNS採fake-ip或依規則分流解析，瀏覽器卻仍自行對CleanBrowsing、Cloudflare、Google Public DNS等供應商解析，核心看到的SNI／目的位址與你在規則裡寫的網域條件可能對不起來，結果就像規則沒命中或出口顯示異常。

排查順序建議：先到chrome://settings/security（或新版設定中的隱私權與安全性 → 安全性 → 使用安全 DNS）將選項改為您的目前服務供應商（意即跟隨系統），或暫時選停用類語意選項，改由Windows網路介面的 DNS 與 Clash 設定對齊。做完後清掉該站快取或以無痕視窗重測，並對照客戶端DNS 日誌是否已回到你預期的本機或上游鏈。

四、對齊 Windows 系統代理與 Clash「寫入系統代理」

Chromium在 Windows 上預設會讀取系統 Proxy設定（除非另行指定指令列或政策）。請在設定 → 網路和網際網路 → Proxy檢查手動 Proxy是否指向127.0.0.1以及與 Clash 客戶端顯示相同的埠號（常見為mixed-port或分拆的HTTP／SOCKS埠，依你的組態為準）。若此處為關閉，Chrome 多半直連；若埠號抄錯，則會連線失敗或回落行為異常。

接著回到 Clash／Verge 類客戶端，確認「設定系統代理」或同等開關是否真的為開啟，且沒有被快速鍵／腳本／另一套軟體立即覆寫。企業環境若有PAC或WPAD，也可能與手動 Proxy互相競爭；此情況下建議先記錄誰最後寫入登錄檔或設定介面，再決定是否改採TUN從路由層統一接管。

五、TUN 模式與「只靠系統代理」的差異

若你希望不依賴應用程式是否支援系統 Proxy，或要一併涵蓋UDP／QUIC與部分略過 Proxy 的程式，可評估開啟TUN（虛擬網卡）讓流量進Mihomo 核心再走規則。請注意：同時開TUN又在 Chrome 外再疊手動 Proxy，偶爾會造成雙重標記或路由環路錯覺，務必以連線紀錄為準。

對TUN載入順序、環境準備與常見坑，建議延伸閱讀《Clash TUN 模式開啟方法》，並與本文「先關 QUIC、對齊 DNS、再看系統 Proxy」的順序並行對照。

六、擴充功能、設定檔與企業政策

若安裝了SwitchyOmega或其他情境代理套件，Chrome 可能優先採用套件 PAC，與 Clash 寫入的系統代理不同步。最快驗證方式是停用該類套件或以乾淨設定檔啟動 Chrome（指令列--user-data-dir指向暫存資料夾）做A／B 測試。

另一類是企業政策（policy）或網域加入（domain join）電腦上的強制 Proxy／DNS；此時 UI 看似可改，重啟後又還原。需往政策檔與登錄檔來源追查，而非只在設定頁反覆切換。

七、用連線紀錄與規則「對答案」

當 QUIC 已關、Secure DNS 已跟隨系統、Windows Proxy 埠號正確，接下來應能在 Clash／Mihomo 的連線紀錄看到 Chrome 造訪目標時對應的策略群組與實際鏈路。若仍不符，請檢查：規則順序是否被DIRECT／MATCH提前截斷；PROCESS-NAME規則是否誤判（某些 Chromium子行程名稱不同）；以及GEOIP／DOMAIN-SUFFIX條件是否涵蓋實際 CDN 後綴。

建議以同一個測試網址重複整理三次紀錄：關 QUIC 前後各一次、改 Secure DNS 前後各一次，通常就能把症狀對應到特定開關，而不是盲目更換節點。

八、建議實測勾選表（濃縮版）

  1. Clash／Mihomo：監聽埠與系統代理開關確認無誤。
  2. chrome://flags：停用 QUIC，完整重啟 Chrome。
  3. 安全 DNS：改為跟隨目前供應商／系統或停用後重測。
  4. Windows Proxy：位址127.0.0.1、埠號與客戶端一致。
  5. 暫停代理類擴充套件或以乾淨設定檔對照。
  6. 必要時啟用TUN並避免重複 Proxy 疊加。
  7. 以連線紀錄核對規則命中與出口。

九、小結

Chrome Windows與Clash同機並存時，「已開代理卻像直連」多數可收斂到QUIC／UDP 路徑、Secure DNS與系統代理三方對齊，再用連線紀錄驗證規則是否真的命中。相較一再更換節點，先把瀏覽器堆疊與OS 代理狀態對齊，通常更快定位問題。若你希望長期少動開關，可評估以TUN統一接管並維持乾淨的DNS／fake-ip策略；日常也可搭配圖形客戶端降低改檔頻率。若尚未完成訂閱與基礎啟動，可先依《Clash Verge Rev 設定教學》把環境跑通，再回頭對照本文逐步檢查。→ 立即免費下載 Clash，開啟流暢上網新體驗