先分桶：你看到的是哪一類「不跟系統」？
同一句「Chrome 不跟系統代理」在現場其實有好幾種樣子。與 本站 Firefox 專文 對讀時，可記一條原則：Firefox 偏向「瀏覽器內層手動值」覆寫，而 Chromium 在 Windows 上則要優先懷疑「啟動命令列＋企業政策＋多使用者設定檔」。
型態 A：整體能開海外站，但顯然沒有經過你預期的那個 Clash 節點（看 IP 測速頁仍像家網出口）。型態 B：多數分頁正常，單一擴充功能或某個內部網域失敗，誤讓人覺得「Chrome 不讀系統」。型態 C：一啟用 Clash TUN 或改 DNS，只有 Chrome 的某些請求不進日誌，最後才發現是 Secure DNS 或 QUIC / HTTP3 路徑與你預期不同。
下列對照表用來在六步內壓低變因：每做完一步，用同一測速頁與同一段 Clash 日誌 驗收，比一次把全部開關都旋到最大更有用。
| 現象 | 較常見原因 | 先到哪一步 |
|---|---|---|
| 全站像直連，但 Edge 有走代理 | Chrome 以捷徑帶了 --no-proxy-server 或自訂 --proxy-server= |
步驟四、五 |
| 顯示「由您的管理員所管理」、無法關擴充 | 企業政策、學校裝置、或殘留 GPO 模板 | 步驟五 |
| 關了所有擴充仍怪，TUN 一開就正常 | 系統寫入代理與實際埠不一致、或雙寫導致衝突 | 步驟一、二、六 |
步驟一：在 Clash 與 Windows 兩邊寫成「能對讀的」事實
首先要避免口頭描述「有開系統代理」卻沒有對上任何一個實際可測的埠。在 Clash Meta 一系圖形客戶端，請同時看見這三行：系統代理開關、混合埠（常見 7890）、SOCKS5 埠；再把 Windows「設定」→「網路與網際網路」→「Proxy」內的手動欄位與之逐字比對（本機 127.0.0.1 與埠號有無一個數字差）。
若你打算讓 Chrome 讀系統，則在開瀏覽器之前先定義實驗條件：實驗 1 只開系統代理、關 TUN，確認 Clash 的開關確實把 WinHTTP 或使用者層的 IE 風格設定寫進去；實驗 2 關系統代理、只開 TUN，觀察是否已無需額外依賴「讀到系統」──這與我們在 TUN 與系統代理差異專文 裡的折返流程一致。若兩實驗一個成功一個失敗，幾乎可以判定問題不在「Chrome 壞了」，而在哪一層在管代理 / 轉送。
需要釐清規則層時，把同一個測站連線丟到 Clash 的連線日誌，看命中的是 DIRECT 還是某策略組。若你剛從 YAML 規則入門 寫了嚴格分流，可很快分辨是「瀏覽器沒進代理管線」還是「已進入 Clash 但被判直連」。
步驟二：在 Windows 釐清「僅目前使用者」與還原預設
在 Windows 10／11 的代理畫面，「還原」與關閉手動常見的陷阱是：只變了目前登入的這個帳戶的設定、或沒有把舊的「手動欄位」淨空。建議在系統夾內以系統內建路徑關一次再開，勿僅在第三方工具內用「一鍵關」代替。
實作上請依序關注：手動是否完全關閉、自動偵測是否因企業關閉、以及你是否曾以匯入腳本在背景改過 WinINet 或服務。若你與團隊共用電腦，可另建一 Windows 帳戶測 30 秒：新帳戶若一登入就正常，幾乎可鎖在「僅此使用者帶的舊代理值」而非 Clash 本身。
還原後，再回到 Clash 以單一模式寫入：要嘛只讓它管理系統代理、要嘛只以 TUN 主導，避免「系統一組、TUN 一組、擴充再一組」讓人無法在瀏覽器端判讀。完成 Windows 層的還原設定後，務必整機重開一次 Chrome 行程（在「工作管理員」結束所有 chrome.exe），因為有時候常駐的後台子程序還吃著啟動當下抓到的舊系統層變數。
步驟三：在 Chrome 內對齊「與系統一致」、排除拚命改連線的擴充
在 Chrome 地址列打開 chrome://settings/system，確認 「在可用時使用系統代理設定」（實際措辭隨版本略異）是否開啟。隨後到 chrome://settings/security 檢查 使用安全 DNS：在 fake-ip 或內部 DNS 專用環境，若讓瀏覽器改用第三方 DoH，常會出現「系統代理有開，但實際解析與 SNI 路徑與你以為的不同」──這不算是 Chrome 不讀系統，而是 DNS 端先分叉了；關掉對照一輪，往往比到處重設代理還快。
接著在 chrome://extensions 暫時逐個關閉廣告攔截、隱私外掛、與自稱能「一鍵切換地區 / 解鎖站」的套件。多數以 PAC 或 local proxy 方式注入，優先權在內部代理鏈裡，容易與 系統寫入的 HTTP / SOCKS 埠打架。建議在關掉所有擴充的狀態下，用無痕視窗 + 一個測速頁做基準，再一個一個加回，快速定位兇手。
若公司要求固定某個內掛，請在擴充說明頁讀其「需要的欄位」；有些會硬性指定不經本機迴路的連線，與 127.0.0.1 上監聽的 Clash 埠天生不合，這時與其硬調瀏覽器，更務實的是回到步驟六 用 TUN 讓上層不再依賴手動/系統的細部組合。
步驟四：看 chrome://version 的「實際命令列」；捷徑與 --proxy-server 一網打盡
在網址列打開 chrome://version，在「命令列」欄位尋找是否出現 --proxy-server=、--proxy-bypass-list=、--no-proxy-server 或 --host-resolver-rules 等。只要這些字串在，它們的效力通常高於圖形介面裡你覺得已經「跟系統」了的選項。這是 Chromium 的設計：方便 IT 一鍵布署，卻讓家用使用者誤以為是「Chrome 壞了不聽系統」。
常見藏參地點包含：工作列捷徑、開始功能表捷徑、安裝第三方「乾淨版啟動器」產生的包裝、以及排程內的「以最高權限以固定參數重啟」。把捷徑目標只保留 chrome.exe 路徑加引號，必要時刪去尾端所有參數後再試一次。若刪參之後行為與 與系統代理 立刻一致，就能結案一半。
在刻意除錯時，你也可以暫時用官方推薦的方式加上 --proxy-server=http://127.0.0.1:你的混合埠，強制讓實測中流量走 本機 Clash，排除「系統欄位沒寫上」的疑雲。實作時請一併注意：帶的協定是 http 還是 socks5h 必須與 Clash 實際監聽內容相符；一個字母拼錯在瀏覽器端就會變成永不結束的轉圈。此技巧僅用於比對，長期還是建議回到單一管線（TUN 或寫好系統代理二選一）。
步驟五：在 chrome://policy 與本機原則裡掃出「靜默鎖」
在網址列打開 chrome://policy，觀察是否有 ProxyMode、ProxyServer、ProxyPacUrl 等關鍵字非空。欄位若顯示已套用，代表不論你怎麼在圖形介面按「還原設定」，企業層都會在每次啟動重灌他的值。學校或公司筆電常見，家用機也能因為安裝過遠控／家長控制軟體而殘留。
在無法變更政策的前提下，實用選項通常只剩兩條：請管理員在 MDM 或 GPO 放寬、或讓 Clash TUN 在稍底層承載，使瀏覽器內的「讀不讀系統」不再是你唯一關心的事──原理與我們在 UWP 與迴環限制專文 裡寫的「不同沙盒、不同讀法」是同一邏輯的延伸。若你確認政策鎖了代理，在本文的語境裡，與其死磕圖形介面，不如直接進步驟六。
家用手動排查時，可一併搜尋本機的 Group Policy 編輯器與 regedit 中與 Chrome 原則 相關的樹，但刪前請先備份。任何修改登錄檔都應有可回滾的還原點；不確定時寧可截圖 chrome://policy 給社群或內部 IT，用可驗證的 JSON 原文溝通，比口頭敘述「有開代理」要省時間。
步驟六：讓 Clash TUN 穩定承載，必要時以啟動參數作保底對照
當 系統層、捷徑、擴充、政策 四掃下來，心智模型應盡量收斂到一條主路徑。對多數人而言，在 Windows 上把 Clash TUN 以正序開好（權限、驅動、與衝突的其它 VPN 關掉），讓 IP 層流量從虛擬介面 進 mihomo，是讓所有 Chromium 子行程都無法「用不知哪來的參數」跳過轉送的務實解。讀到這裡若仍不確定 TUN 與只開系統的差，請回到專欄的 TUN 斷網與權限總覽 做完「關 TUN 能恢復上網」的基本安全檢查，再重開 TUN 做本文的實驗。
在 TUN 工作正常、但你仍要驗證本機混合埠沒有壞時，可臨時建一顆專用捷徑，目標在 chrome.exe 之後帶上 --proxy-server=http://127.0.0.1:混合埠 與一個最短的 --user-data-dir 空白設定檔路徑，避免誤觸你日常設定裡的擴充。若這顆「分離設定檔＋寫死 proxy」的 Chrome 一開即正常，則幾乎可結案是原設定檔內的擴充、政策或快取，而不是 TUN/Clash 沒有轉好。
最後在 DNS 一側，當 TUN 與 fake-ip 同時在場，請併讀 Fake-IP 與 Redir-Host 選擇，避免以為「Chrome 不讀」實則是子網域沒有命中、或 SNI 與你規則裡的 DOMAIN 不一致。把斷網排查從最外圍的「有沒有看系統」一路收到規則層，是這篇文與 Firefox 專文刻意區分的兩條瀏覽器堆疊路徑，也方便你在社群問問題時一次講清。
常見問答（與實戰用語速查）
問：我按了「還原」Chrome 的設定，為什麼還是怪？答：此按鈕多數不會刪你登入帳戶、也不保證刪到「由管理員安裝」的擴充、更不會掃 --proxy-server。要回到乾淨狀態，需搭配本文步驟四、五。若你只想快速排除，新建使用者設定檔測 30 秒，往往比還原整包更快。
問：TUN 開了，為什麼 curl 與 Edge 一個樣、Chrome 另一個樣？答：多數是讀圖一時爽、看命令列一生黑。請以 chrome://version 為準，少信「圖上顯示與系統相同」這句口頭敘述。
問：我該不該關掉 QUIC 試試？答：在極少數中繼上確實會有 HTTP3 行為看起來像繞，但優先仍應完成政策與 TUN 的主線；若仍卡，可暫以旗標關掉 QUIC 做 A/B 測，並在社群貼上有無 TUN 下的對照日誌。
寫在最後：讓 Windows、Chromium 啟動列 與 Clash TUN 同檯講實話
相較「感覺 Chrome 不聽話」，實作上更精準的說法是：在這台 Windows 上，最後是誰寫了代理欄位、誰在捷徑帶參、誰在 policy 上鎖，以及 TUN 有沒有把上層應用該看見的世界整平。當你照著六步把這四件事拆開，幾乎不會再需要靠重灌來賭博。
一體化、已內建 Meta 核心、並把 TUN 與訂閱匯入放在同一路徑的 Clash 用戶端，能把「系統寫入」與「虛擬介面轉送」變成可觀測的開關，讓多數人不必手刻腳本。若你希望盡快回到「選節點、寫分流」而不是在瀏覽器裡和旗標相面，歡迎從本站包好的安裝路徑開始。
想延伸閱讀，建議一併收藏 Firefox 與 TUN 對照專文 與 專欄首頁 上關於 YAML 與 DNS 的實戰分線；團隊若同時有開發者，亦可參考 終端與瀏覽器並行代理的場景筆記，釐清環境變數與系統層的邊界。