Clash 系統代理已啟用卻無效？瀏覽器與終端機分開排查

先釐清：請求未進入用戶端，還是進入後連線失敗

「系統代理已啟用」只表示用戶端嘗試修改作業系統的代理設定，不代表每個應用程式都會讀取這些設定。瀏覽器可能由擴充功能接管，終端機工具可能只讀取環境變數；即使請求已進入 Clash，也可能依規則分流至 DIRECT，或因節點連線失敗而無法完成。

本文主要適用於 Windows、macOS 和 Linux 桌面版。Clash 是代理核心及相關用戶端生態系常用的稱呼；Clash Meta 後續改名為 mihomo。各用戶端的開關位置不盡相同，核心名稱也不會決定介面選單。Android、iOS 透過 VPN 接管流量的方式與桌面系統代理不同，不宜直接套用本文的系統設定步驟。

1. 在用戶端確認設定檔已載入，出站模式先選「規則」，並記下目前策略群組選用的節點。
2. 開啟用戶端的「連線」頁面，同時查看「日誌」；必要時暫時將日誌層級調整為 info。
3. 向明確指定的目標網域發出新請求，確認連線時間、目標位址、命中規則及出站路徑。
4. 沒有紀錄，先檢查應用程式的流量入口；有紀錄且走 DIRECT，先檢查規則；有紀錄但連線逾時，再檢查節點、DNS 與遠端服務。

本機入口：確認位址、連接埠與核心狀態

以下統一以 127.0.0.1:7890 為例。7890 是常見的設定值，不是所有用戶端都固定使用的連接埠。先到用戶端「設定」中的「連接埠」或「混合連接埠」查看實際數值，再替換命令中的連接埠。請勿將控制器連接埠或儀表板位址誤填為代理連接埠。

Windows：檢查連接埠監聽狀態與所屬程序

netstat -ano | findstr :7890

在輸出結果中尋找本機位址為 127.0.0.1:7890 或相應監聽位址，且狀態為 LISTENING 的列。記下最右欄的 PID，再到「工作管理員」→「詳細資料」確認程序。若連接埠已被其他用戶端占用，目前的用戶端可能成功啟動介面，但核心無法繫結連接埠。

macOS、Linux：檢查 TCP 監聽狀態

lsof -nP -iTCP:7890 -sTCP:LISTEN

若系統未安裝 lsof，Linux 可使用 ss -lntp 查看監聽清單。若沒有監聽項目，先檢查核心啟動日誌、設定解析錯誤與連接埠衝突，不要急著調整瀏覽器。若只供本機使用，通常不必啟用「允許區域網路連線」，也不需要將監聽位址設為所有網路介面。

瀏覽器排查：系統設定、擴充功能、PAC 與例外清單

檢查作業系統實際儲存的代理位址

• Windows 11：開啟「設定」→「網路和網際網路」→「Proxy」。確認「手動設定 Proxy」中的伺服器與連接埠，並檢查「使用設定指令碼」是否仍指向舊的 PAC 位址。
• macOS 13 及以上版本：開啟「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「Proxy」。確認「網頁 Proxy（HTTP）」、「安全網頁 Proxy（HTTPS）」及「自動 Proxy 設定」。切換 Wi-Fi 或有線網路後，請重新確認對應的網路服務。
• GNOME 桌面：通常可在「設定」→「網路」→「網路 Proxy」中查看。不同桌面環境的系統代理設定並不相同，應用程式也未必會讀取同一組設定。

HTTP 代理位址通常填入 127.0.0.1，並在連接埠欄位另填 7890。HTTPS 網站會透過 HTTP 代理的 CONNECT 通道存取，不代表代理伺服器位址必須以 https:// 開頭。輸入欄位是否需要協定前綴，請依系統介面的要求填寫。

Chrome、Edge：檢查擴充功能與政策覆寫

在 Chrome 網址列開啟 chrome://settings/system，或在 Edge 開啟 edge://settings/system，進入系統代理設定。接著分別檢查 chrome://extensions 或 edge://extensions，暫時停用代理切換類擴充功能，完全關閉瀏覽器後再重新開啟。

無痕視窗並非充分的隔離測試：部分擴充功能獲准在無痕模式中執行，系統代理與企業政策也仍然有效。受管理的裝置還應查看 chrome://policy 或 edge://policy；如果代理設定由組織政策固定，請聯絡管理員，不要反覆覆寫設定。

Firefox：確認獨立的網路設定

在 Firefox 開啟「設定」→「一般」→頁面底部的「網路設定」→「設定」。選擇「使用系統 Proxy 設定」，才會依系統設定連線；若選擇「手動 Proxy 設定」，則需確認 HTTP Proxy、連接埠，以及 HTTPS 是否使用同一個 Proxy。「不使用 Proxy」與「自動偵測此網路的 Proxy 設定」都不等於讀取目前用戶端寫入的手動代理設定。

PAC 與繞過清單：依網域分流可能發生在用戶端之前

PAC 指令碼可針對不同 URL 回傳 DIRECT 或代理位址。如果 PAC 對目標網域回傳 DIRECT，請求就不會進入 Clash，本機規則也無法接手。排查時先記下原始設定，暫時只保留一種代理入口，例如關閉自動指令碼後改用手動 HTTP 代理，再以相同目標重新測試。

也請檢查 Windows 的 Proxy 例外清單、macOS 的「略過這些主機與網域的 Proxy 設定」，以及 Firefox 的「不使用 Proxy」清單。localhost、127.0.0.1 和內部網域常會被略過，因此不能用存取本機頁面來判斷外部流量是否進入代理。測試時請發出新請求，並查看用戶端是否出現相應網域的連線，避免受到瀏覽器快取影響。

終端機排查：先明確指定代理，再檢查環境變數

終端機是程序的啟動環境，不是瀏覽器。curl、Git、套件管理工具與指令碼執行環境各有不同的代理讀取方式；開啟桌面系統代理，不保證這些工具會自動使用代理。先讓單次請求明確連線至本機入口，可避開大部分環境變數與應用程式設定的干擾。

使用 curl 進行最基本的測試

在 macOS 或 Linux 執行下方命令。Windows PowerShell 使用相同參數，但請將命令名稱寫成 curl.exe，避免 Windows PowerShell 5.1 中的 curl 別名指向其他命令。

curl -v --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

--noproxy "" 用於清除本次請求的繞過清單；--connect-timeout 10 和 --max-time 20 分別設定連線階段與整個請求的逾時秒數。目標為 HTTPS 時，日誌通常會先顯示連線至本機代理，再顯示 CONNECT 通道的建立過程。200 Connection established 只代表通道已建立，不保證後續 TLS 握手與網頁請求一定成功。

• Connection refused：優先檢查本機連接埠、監聽位址及核心是否正在執行。
• 已連上本機連接埠，但 CONNECT 或後續請求逾時：查看用戶端日誌，檢查策略群組、節點與目標服務。
• 明確指定代理後成功，一般 curl 失敗：優先檢查環境變數與工具本身的設定。
• 憑證錯誤：檢查系統時間、憑證信任鏈與受管理網路；不要將停用憑證驗證當作長期解決方案。

macOS、Linux：在目前的 shell 設定變數

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1
curl -v --connect-timeout 10 --max-time 20 https://example.com/

https_proxy 表示連線至 HTTPS 目標時使用的代理，變數值仍可使用 http://。curl 的 HTTP 代理變數只接受小寫 http_proxy，不接受大寫 HTTP_PROXY；其他工具對大小寫的支援也不同，不能假設所有程式的行為一致。

這些 export 只會影響目前的 shell 及其後續子程序，不會修改已啟動的程式。測試成功後，再依實際使用的 shell 將設定寫入 ~/.zshrc 或 ~/.bashrc 等啟動檔案。IDE 內嵌終端機可能沿用 IDE 啟動時的舊環境，請關閉並重新啟動相關程序。

Windows PowerShell：設定目前工作階段的環境

$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"
$env:no_proxy = "localhost,127.0.0.1,::1"
curl.exe -v --connect-timeout 10 --max-time 20 https://example.com/

關閉目前視窗後，這些指派不會自動保留。Windows 桌面代理、WinHTTP 代理與程序環境變數是不同的設定入口；netsh winhttp show proxy 顯示的結果，不能代表瀏覽器或 curl 的所有行為。只有確認目標程式使用 WinHTTP 時，才需要繼續檢查這條路徑。

清除殘留變數與應用程式層級代理

macOS、Linux 可執行 env | grep -i proxy；PowerShell 可執行 Get-ChildItem Env:*proxy*。優先檢查指向舊連接埠的 ALL_PROXY、大寫變數，以及範圍過廣的 NO_PROXY。對 curl 而言，符合協定的代理變數通常優先於 ALL_PROXY，而繞過清單可能讓請求直接連線。

若只有 Git 失敗，可使用 git config --show-origin --get-regexp '.*proxy.*' 查看設定來源。套件管理工具也可能有獨立的代理設定，請針對實際使用的工具檢查，不要同時修改所有全域設定。測試完成後，可在 Unix shell 使用下方命令移除目前工作階段中常見的代理變數：

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

請求已進入 Clash：檢查規則、DNS 與出站路徑

如果瀏覽器與 curl 的目標都出現在用戶端的連線清單中，代表入口已暢通。此時繼續切換系統代理通常沒有幫助。開啟對應的連線詳細資料，依序確認目標網域、命中規則、策略群組與最後使用的節點。

1. 命中 DIRECT 規則：確認是否符合預期。規則通常由上而下比對，前面的直連規則可能先於後面的代理規則生效；也請確認規則集已成功載入。
2. 策略群組選用 DIRECT：即使命中代理策略群組，群組內手動選取的項目仍可能是 DIRECT。請確認實際選項，而不只看群組名稱。
3. 節點連線失敗：改用同一群組中的其他節點，對相同目標重試。延遲測試成功只代表測試目標可連線，不保證所有網站都能存取。
4. DNS 錯誤：查看日誌，判斷是目標網域解析失敗、代理伺服器網域解析失敗，還是無法連線至 DNS 伺服器。原因未釐清前，不要同時更換 DNS、規則與節點。

若要確認問題是否出在規則，可暫時切換至「全域」模式，並明確選取一個代理節點，完成單次測試後再切回「規則」。全域模式只會變更進入核心後的出站選擇，不會強制未使用代理的應用程式進入用戶端。

TUN 模式的取捨：供不讀取代理設定的應用程式使用

若瀏覽器與明確指定代理的測試都正常，但部分應用程式完全不讀取系統代理或環境變數，可考慮使用 TUN 模式。TUN 透過虛擬網卡與路由接管流量，適合需要統一處理更多 TCP、UDP 流量的情境；實際涵蓋範圍取決於路由、排除項目、核心設定與平台權限，啟用後並不代表所有連線都一定會經由遠端節點。

• Windows：依用戶端要求安裝服務模式或授予系統管理員權限，再啟用 TUN，並確認虛擬網卡與路由是否成功建立。
• macOS：依用戶端要求安裝輔助服務並授權相關網路功能；若啟動失敗，先檢查權限與路由日誌。
• Linux：確認 TUN 裝置可用，並依用戶端的部署方式授予網路管理所需權限。容器或受限制的環境可能無法建立虛擬網卡。

mihomo 常見的 TUN 設定會用到 enable、stack、auto-route 和 dns-hijack 等欄位，但不同版本與用戶端可能會透過介面產生設定。請優先使用目前用戶端提供的開關，不要將其他平台的完整設定直接覆蓋現有訂閱。

排查 TUN 時，先退出其他 VPN 或類似的路由接管用戶端，再依序測試 DNS、網頁、終端機與區域網路服務。公司 VPN、虛擬機網卡與容器網路可能和自動路由衝突。啟用後若無法連線至本機服務，應檢查排除網段與路由，而不是盲目刪除所有例外。

若只需要讓 curl、Git 等少數工具使用代理，明確指定參數或設定環境變數通常更容易找出問題；若要涵蓋不支援代理設定的應用程式，再考慮使用 TUN。若啟用 TUN 後立即斷網，請先關閉 TUN 恢復網路，再檢查權限、DNS 與路由日誌。

重新測試清單：使用同一目標，分別驗證三條路徑

最後固定一個目標網域，依序測試明確指定代理的 curl、瀏覽器，以及未帶明確參數的終端機請求。每次都記錄用戶端是否收到連線、命中哪條規則，以及最後使用的出站路徑。確認三條路徑後，再恢復所需的 PAC、擴充功能或 TUN 設定，並將暫時調整的日誌層級改回日常使用值。