Clash 系統代理無法使用怎麼排查：分別驗證瀏覽器與終端機

先確認問題發生在哪一層

「系統代理已開啟」只代表客戶端嘗試將 HTTP 與 HTTPS 代理位址寫入作業系統設定，不代表所有程式都會讀取這項設定。Chrome、Edge 等瀏覽器通常會遵循系統代理；Firefox 可以使用系統設定，也可以保留一套獨立代理；終端機中的 Git、curl、npm、Python 與容器工具則經常繞過系統代理，改讀環境變數或各自的設定檔。

排查時不要先更換節點、重新安裝客戶端或反覆匯入訂閱。先將連線鏈路拆成四段：Clash 核心是否執行、監聽連接埠是否存在、目標程式是否將連線交給該連接埠，以及連線進入 Clash 後命中了哪項規則。只要逐層驗證，就能判斷故障位於客戶端、作業系統、應用程式或規則設定。

觀察結果	優先檢查	常見原因
瀏覽器和終端機都無法使用代理	核心、連接埠與設定狀態	核心未啟動、連接埠遭占用、設定載入失敗
瀏覽器正常，終端機直連	終端機環境變數與工具設定	命令列程式不讀取系統代理
終端機明確指定代理後正常，瀏覽器直連	系統代理與瀏覽器設定	系統代理未寫入、擴充功能覆寫、瀏覽器使用獨立設定
連線進入日誌但網站無法開啟	規則、節點、DNS 與憑證錯誤	命中 REJECT、節點無法使用、網域解析異常
一般程式正常，遊戲或 UWP 應用程式異常	TUN、回環限制與 UDP 支援	程式不使用 HTTP 代理或需要 UDP 轉發

記錄實際連接埠，不要直接套用 7890

許多設定會使用 7890 作為 mixed-port，但這不是強制值。不同客戶端可能顯示 HTTP、SOCKS5 與混合連接埠，連接埠也可能被設定檔覆寫。開啟客戶端的「設定」→「連接埠設定」或「設定」→「Clash 設定」，記錄目前正在監聽的位址與連接埠。若介面顯示混合連接埠為 7890，後續指令才使用此數值。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port 同時接受 HTTP 與 SOCKS5 連線。若設定分別使用 port: 7890 與 socks-port: 7891，測試指令必須對應正確協定。將 SOCKS5 請求傳送至僅接受 HTTP 的連接埠，通常會得到連線重設或代理交握失敗，而不是明確顯示「連接埠類型錯誤」。

瀏覽器路線：檢查系統代理與擴充功能覆寫

第一步：核對作業系統中的代理位址

Windows 11 可進入「設定」→「網路和網際網路」→「代理」，查看「使用代理伺服器」是否已開啟。位址通常是 127.0.0.1，連接埠應與 Clash 目前的 HTTP 或混合連接埠一致。若客戶端已顯示系統代理開啟，而 Windows 頁面仍是舊連接埠，先關閉客戶端中的系統代理開關，再重新開啟一次。

macOS 可進入「系統設定」→「網路」→目前網路介面→「詳細資訊」→「代理伺服器」。常見設定會同時勾選「網頁代理伺服器（HTTP）」與「安全網頁代理伺服器（HTTPS）」，伺服器填寫 127.0.0.1，連接埠填寫客戶端顯示的 HTTP 或 mixed 連接埠。僅設定 SOCKS 代理時，應用程式是否使用它取決於應用程式本身的實作。

系統代理中不應填寫節點伺服器位址。系統設定的目標是本機 Clash 監聽位址，例如 127.0.0.1:7890；節點位址、驗證資訊與傳輸參數由 Clash 設定處理。若將遠端節點連接埠直接寫入系統代理，通常無法完成相應的協定交握。

第二步：排除瀏覽器獨立代理與擴充功能衝突

Chrome 和 Edge 預設會讀取系統代理，但代理切換擴充功能可能覆寫這條路徑。先開啟無痕視窗測試；如果擴充功能允許在無痕模式執行，還需要在擴充功能管理頁暫時停用代理類擴充功能。重點檢查 SwitchyOmega 的替代擴充功能、企業策略代理、封包擷取工具與除錯代理。多個工具同時控制代理時，最後寫入設定或優先級較高的一方會決定實際出口。

Firefox 需要另外查看「設定」→「一般」→「網路設定」→「設定」。選擇「使用系統代理設定」才能跟隨 Clash 寫入的系統值；選擇「手動代理設定」時，應填寫目前的本機連接埠；選擇「不使用代理」則會直接連線。Firefox 的「自動偵測此網路的代理設定」也不等同於跟隨系統代理。

第三步：透過日誌確認瀏覽器請求是否進入 Clash

開啟客戶端的「日誌」頁面，將日誌層級維持在 info。
關閉瀏覽器中正在自動重新整理的頁面，減少背景請求干擾。
新增分頁，造訪一個先前未開啟的 HTTPS 網站。
在日誌中搜尋該網域，觀察連線來源、命中規則與最終策略。

如果日誌完全沒有出現該網域，問題位於瀏覽器到本機連接埠之間，應繼續檢查系統代理、瀏覽器策略與擴充功能。若日誌出現 MATCH、DOMAIN-SUFFIX 等規則，並顯示某個代理群組或 DIRECT，表示瀏覽器已將請求交給 Clash，接下來要檢查規則選擇與節點狀態。

瀏覽器顯示的快取頁面不能證明目前代理有效。建議使用開發人員工具的「網路」面板勾選「停用快取」，再執行一次強制重新整理。也可以同時觀察 Clash 的「連線」頁面：新連線應顯示目標網域、網路類型、上傳下載流量與命中鏈路。

終端機路線：明確指定代理驗證連接埠

終端機程式的行為不能從瀏覽器結果推斷。最可靠的做法是先讓單一指令明確指定代理。如果明確指定代理後成功，再設定環境變數或工具層級參數；如果明確指定代理也失敗，則回頭檢查本機連接埠、核心狀態與防火牆。

使用 curl 直接測試 HTTP 代理

在 Windows PowerShell 5.1 中，curl 可能是 Invoke-WebRequest 的別名，應明確執行 curl.exe。Windows 10 較新版本與 Windows 11 通常內建 curl。假設 mixed-port 為 7890，執行：

curl.exe -v -x http://127.0.0.1:7890 https://example.com/

macOS、Linux、Git Bash 或已安裝獨立 curl 的環境可執行：

curl -v -x http://127.0.0.1:7890 https://example.com/

詳細輸出中若出現 Connected to 127.0.0.1，以及對 HTTPS 目標發出的 CONNECT 請求，表示 curl 已連線至本機代理。隨後返回 HTTP 狀態碼，且 Clash 日誌出現目標網域，代表代理鏈路已建立。若立即出現 Connection refused，表示該連接埠沒有監聽，或填寫了錯誤的連接埠。

使用 SOCKS5 並讓 Clash 解析網域

SOCKS5 測試建議使用 socks5h。結尾的 h 表示將網域交由代理解析，可避免本機 DNS 結果影響測試。連接埠應填寫 SOCKS 連接埠或 mixed-port：

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

socks5:// 與 socks5h:// 的差異主要在於網域解析位置。前者通常先在本機解析，再將 IP 交給代理；後者則將網域放入 SOCKS 請求。排查網域污染、依賴網域分流或本機 DNS 不穩定時，優先使用 socks5h。

設定目前終端機工作階段的環境變數

在 PowerShell 中，可以只為目前視窗設定代理。關閉視窗後變數即失效，適合用於故障驗證：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -v https://example.com/

在 macOS、Linux、WSL 或 Git Bash 中，可同時設定大寫與小寫變數，因為不同程式讀取規則並不完全一致：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -v https://example.com/

還要檢查 NO_PROXY 與 no_proxy。如果目標網域、網域後綴或萬用字元範圍出現在排除清單中，程式會主動繞過代理。以下設定只讓本機位址直連：

export NO_PROXY=localhost,127.0.0.1,::1
export no_proxy=localhost,127.0.0.1,::1

Git、npm 與 Python 可能各自儲存代理設定

Git 可以讀取環境變數，也可能在全域設定中保留舊連接埠。先查看目前設定來源，再決定是否修改：

git config --global --get http.proxy
git config --global --get https.proxy
git config --show-origin --get-regexp "http\..*proxy"

需要為 Git 明確設定本機代理時，可使用：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

npm 可透過 npm config get proxy 與 npm config get https-proxy 檢查設定。Python 的 pip 既可能讀取 HTTPS_PROXY，也可以透過單次參數測試：

python -m pip install --proxy http://127.0.0.1:7890 套件名稱

工具設定中的舊連接埠很容易造成誤判：瀏覽器已切換到新的 7890，Git 卻仍連線至之前的 7897。因此每次變更 Clash 監聽連接埠後，都應重新檢查環境變數、Git 設定、npm 設定、IDE 終端機與容器環境。

確認核心與連接埠是否確實監聽

Windows 查看監聽程序

在 PowerShell 或命令提示字元中執行以下指令，檢查 7890 是否處於 LISTENING 狀態：

netstat -ano | findstr :7890

輸出末尾是程序 PID。可以繼續查詢程序名稱：

tasklist /FI "PID eq 程序編號"

如果占用該連接埠的不是目前的 Clash 客戶端，請修改監聽連接埠或結束衝突程序。若沒有任何輸出，回到客戶端檢查核心狀態與設定錯誤。設定解析失敗時，圖形介面可能仍保持開啟，但代理連接埠不會依預期建立。

macOS 與 Linux 查看監聽位址

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux 也可以使用：

ss -lntp | grep 7890

監聽在 127.0.0.1:7890 時，僅本機程式可存取，這是桌面使用的常見設定。區域網路中的其他裝置若要連接該連接埠，需要客戶端開啟「允許區域網路連線」，將設定中的 allow-lan 設為 true，並確認監聽位址與系統防火牆允許對應網路存取。不要為了排查本機瀏覽器問題而改成區域網路監聽。

日誌出現連線後再檢查規則

Clash 的規則通常依照由上至下的順序比對，先命中的規則生效。網域可能先命中 DOMAIN、DOMAIN-SUFFIX 或規則集；只有前面都未命中時，才會進入最終的 MATCH。如果測試請求命中 REJECT，連線會被主動拒絕；命中 DIRECT，則由本機網路直接存取。

切換至全域模式後恢復正常，通常表示連接埠、系統代理與節點鏈路都已成立，故障集中在規則或策略群組。此時記錄日誌中的規則名稱與策略群組，檢查該群組是否選取了可用節點。不要長期停留在全域模式來掩蓋規則問題，因為區域網路位址、軟體更新與本機服務也可能被不必要地送入代理。

系統代理無法處理的程式：判斷是否需要 TUN

系統代理主要涵蓋主動支援 HTTP 或 SOCKS 代理的應用程式。部分遊戲、命令列程式、商店應用程式、虛擬機器、容器與使用自訂網路堆疊的軟體不會讀取系統設定。此時，即使瀏覽器完全正常，這些程式仍可能直接連線。

TUN 模式透過虛擬網路介面接管更多 IP 流量，再交由 mihomo 等相容核心處理。它適合無法單獨設定代理、需要 UDP，或希望統一接管應用程式連線的情境。TUN 不是「系統代理增強開關」，其執行依賴系統權限、路由、DNS 劫持方式與虛擬網卡狀態。

啟用 TUN 前先確認三項條件

一般 HTTP 代理測試已成功，確保節點與設定本身可用。
客戶端使用支援 TUN 的 Clash Meta 或 mihomo 核心，並已完成服務模式或系統管理員權限設定。
系統中沒有另一套 VPN、虛擬網卡或安全軟體同時修改預設路由與 DNS。

啟用後應檢查客戶端日誌是否出現 TUN 介面建立成功的訊息，再觀察目標程式的連線是否進入 Clash。Windows 上若只有特定 UWP 應用程式無法連線，還要考慮應用程式回環限制；部分客戶端提供 UWP Loopback 輔助入口。這個問題與一般桌面瀏覽器的系統代理設定不在同一層。

如果啟用 TUN 後整個系統無法解析網域，先關閉 TUN 以恢復網路，再檢查 DNS 設定、虛擬網卡與其他 VPN 衝突。不要同時變更節點、規則、DNS 與路由，否則難以判斷是哪一項造成變化。

依結果收斂：一套可重現的排查順序

確認客戶端核心處於執行狀態，設定頁面沒有解析錯誤。
從客戶端介面讀取實際的 HTTP、SOCKS5 或 mixed-port，不預設連接埠號碼。
使用 netstat、lsof 或 ss 確認連接埠正在監聽。
暫時切換至全域模式，選擇一個已確認可用的節點。
在瀏覽器路線中核對系統代理、Firefox 獨立設定與代理擴充功能。
開啟 Clash 日誌，造訪新網域，確認請求是否進入核心。
在終端機使用 curl -x 明確指定代理，不先依賴環境變數。
明確測試成功後，再設定 HTTP_PROXY、HTTPS_PROXY 或工具層級代理。
切回規則模式，依據日誌確認命中的規則、策略群組與最終出口。
僅當應用程式不支援系統代理時，再評估 TUN、UWP 回環或容器網路。

這套順序的關鍵是每一步只驗證一個變數。瀏覽器無法連線而明確指定 curl 成功，請檢查系統代理與瀏覽器；瀏覽器正常但終端機無法連線，請檢查環境變數與工具設定；兩者都無法連線至本機連接埠，請檢查核心與監聽狀態；請求已進入日誌但結果異常，請檢查規則、節點與 DNS。將「系統代理無法使用」拆解為這些可觀察的結果後，通常不需要重新安裝客戶端。