Clash 系統代理不生效的排查方法:瀏覽器與終端分別處理

先做三分鐘基礎確認

很多「系統代理不生效」的狀況,其實卡在最基礎的一層。動手改任何設定之前,先依序把下面四項確認一遍,大多能直接找出問題所在。

1. 確認用戶端確實在執行。系統列能看到圖示、主畫面能正常開啟,而不是縮到背景後已經悄悄退出。
2. 確認節點可用。在代理頁對目前節點做一次延遲測試,超時或延遲異常的節點先換掉。系統代理只是入口,節點不通,入口設對了也沒用。
3. 確認系統代理真的寫進了系統。用戶端裡開關顯示「已開啟」還不夠,要到作業系統裡看實際數值:Windows 在「設定 → 網路和網際網路 → 代理伺服器」裡看「使用 Proxy 伺服器」;macOS 在「系統設定 → 網路 → 詳細資訊 → 代理伺服器」裡看網頁代理伺服器與安全網頁代理伺服器;Linux(GNOME)在「設定 → 網路 → 網路代理」裡看是否為手動模式。位址應為 127.0.0.1,埠號要與用戶端一致。
4. 確認埠號對得上。用戶端設定頁顯示的埠號必須與系統裡寫入的埠號相同。改過埠號卻忘了重新切換開關,是常見的踩雷點。

系統代理開關到底做了什麼

理解原理能省掉一半瞎試。這個開關只做一件事:把「127.0.0.1 + 用戶端監聽埠號」寫進作業系統的代理設定。之後,凡是遵循系統代理的應用程式——絕大多數瀏覽器與桌面軟體——發起連線時會先把流量交給 Clash 核心,由核心依規則分流;不讀系統代理的應用程式則完全不受影響,命令列工具就是最典型的一類。

因此「開關開了沒效果」只可能出在三個地方:

• 寫入失敗:系統裡根本沒有這條設定,常見於權限不足、被安全軟體攔截、被另一個代理軟體搶占。
• 應用程式不讀:應用程式使用自己的代理設定,或根本不看系統代理。
• 入口不通:設定寫對了,但 Clash 的埠號沒在監聽,或目前節點不可用。

第一、三種在上一節的基礎確認裡就能排除。剩下的,按瀏覽器與終端兩條線分別處理。

瀏覽器路線:先查擴充功能與獨立設定

先用一條指令確認 Clash 入口本身是通的。開啟終端機,明確指定代理存取 IP 查詢介面:

curl -x http://127.0.0.1:7890 https://api.ip.sb

回傳的應該是節點出口 IP。這一步就失敗,說明問題出在用戶端或節點,與瀏覽器無關,回到第一節處理;這一步正常但瀏覽器不生效,再依下面順序查:

1. 停用代理類擴充功能。SwitchyOmega 一類的擴充功能會接管瀏覽器代理,優先權高於系統設定。先全部停用再測,確認恢復後逐一啟用,找出是哪一個在搶。
2. 用隱私瀏覽視窗對照。隱私瀏覽模式預設不載入擴充功能,若隱私瀏覽視窗正常、一般視窗不正常,基本可以判定是擴充功能在搶代理。
3. 檢查 Firefox 的獨立設定。Firefox 的代理設定獨立於系統面板,若之前手動改過,到「設定 → 網路設定」裡確認選回「使用系統代理設定」。
4. 清掉殘留的自動設定腳本。系統代理裡若留著「使用自動代理設定(PAC)」位址,瀏覽器會照腳本走而不是走 Clash,把該項關閉。
5. 用出口 IP 做最終對照。開啟 IP 查詢網站,切換節點後重新整理,出口 IP 跟著變,表示連線已通;個別網站仍打不開,那是規則或節點的問題,已經不是系統代理的問題。

終端路線:命令列不讀系統代理

這是最常見的誤會:終端機以及裡面的 curl、git、npm 預設完全不讀系統代理,開關開再久它們照樣直連。終端機要走代理,得另外設定環境變數。

macOS / Linux(bash、zsh):

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

Windows PowerShell:

$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"

Windows cmd:

set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890

設定完執行 curl https://api.ip.sb 驗證,回傳節點 IP 即生效。還有幾個細節值得記住:

• 環境變數只對目前視窗生效,關閉視窗即失效;想長期生效,寫進 shell 設定檔(如 ~/.zshrc)。
• 只想讓單條指令走代理,在 macOS / Linux 下可以臨時加前綴:https_proxy=http://127.0.0.1:7890 curl https://api.ip.sb。
• 存取本機與內網位址應繞過代理:export no_proxy=localhost,127.0.0.1。
• 取消終端代理:macOS / Linux 執行 unset http_proxy https_proxy all_proxy;PowerShell 把對應變數重新設為空即可。
• git 走自己的設定,部分環境下不看環境變數:git config --global http.proxy http://127.0.0.1:7890;取消用 git config --global --unset http.proxy。注意這只影響 HTTP(S)遠端,SSH 遠端不受影響。

埠號衝突:監聽失敗時開關形同虛設

埠號被其他程式占用時,Clash 的埠號監聽會失敗——開關照常能開、系統設定照常寫入,但入口後面沒有服務在接流量,表現就是「開了跟沒開一樣」。 先查埠號被誰占用。Windows(PowerShell 或 cmd): ```bash netstat -ano | findstr :7890 ``` 有輸出說明埠號已被占用,最後一欄是占用行程的 PID,再用 `tasklist | findstr ` 看具體是哪個程式。macOS / Linux: ```bash lsof -i :7890 ``` Linux 上也可以執行 `ss -lntp | grep 7890`。如果輸出裡的行程根本不是你的 Clash 用戶端,衝突就確定了。處理有兩條路: - 改埠號:在用戶端設定頁把 mixed 埠號換成一個空閒值(如 7897),儲存後把系統代理開關關掉再開一次,讓新埠號重新寫入系統。 - 讓出埠號:最常見的占用者是另一個沒退乾淨的代理用戶端,或上一次異常退出殘留的行程。從系統列退出,或直接結束對應行程。

權限、殘留與多用戶端互搶

埠號正常卻仍不生效,往下查這三類常見原因:

1. macOS 授權被取消。首次開啟系統代理時系統會彈出授權框要求輸入密碼,按下「取消」則寫入失敗——開關看起來是開的,系統裡其實沒寫。重新切換開關,這次完成授權。
2. 安全軟體攔截。Windows 上部分安全軟體會攔截第三方程式修改系統代理,把用戶端加入信任清單後重新切換開關。
3. 多用戶端互搶。同時執行兩個代理用戶端,後開的會覆蓋先開的寫入系統代理,先開的那個自然「不生效」。同一時間只保留一個。

還有一個反向問題值得知道:退出用戶端前沒關系統代理,系統裡會一直留著 127.0.0.1:7890 這條設定,而本機已經沒有服務在監聽,表現為「關了 Clash 反而斷網」。解法是重新開啟用戶端把開關關一次,或手動到系統代理設定裡把它關掉。

企業或校園裝置若被群組原則、設定描述檔鎖定代理設定,手動寫入會被立即改回。這種環境不必再折騰系統代理,直接走終端環境變數,或看下一節的 TUN 模式。

終端工具多,直接換 TUN 模式

系統代理天生的短板是「依賴應用程式配合」:應用程式不讀系統設定,開關就管不到它。日常要在終端機裡跑 git、npm、docker 的用戶,更省心的方案是 TUN 模式——它建立一張虛擬網卡,在系統網路層接管全域流量,不挑應用程式,命令列工具無需任何設定就會自動走代理。

以 mihomo 核心為基礎的用戶端(Clash Verge Rev、Clash Nyanpasu、FlClash 等)都在設定頁提供 TUN 開關;Windows 與 macOS 上首次開啟通常需要安裝服務模式或完成一次管理員授權。TUN 與系統代理可以同時開,兩者不衝突,TUN 在路由層接管,系統代理管應用層,各走各的。

一頁複查清單

排查陷入僵局時,依這份清單從頭過一遍:

1. 用戶端在執行,目前節點延遲測試通過。
2. 系統代理設定裡能看到 127.0.0.1,埠號與用戶端設定頁一致。
3. 命令列執行 curl -x http://127.0.0.1:7890 https://api.ip.sb 回傳節點 IP。
4. 瀏覽器停用全部代理類擴充功能,以隱私瀏覽視窗對照測試。
5. 終端機另外設定 http_proxy / https_proxy 環境變數。
6. netstat 或 lsof 確認埠號無衝突,改埠號後重新切換開關。
7. 只保留一個代理用戶端,退出前先關系統代理。
8. 終端需求多,改用 TUN 模式接管全域。

絕大多數「系統代理不生效」到第三步就能分出方向:入口通,查應用程式;入口不通,查用戶端與埠號。按線排查,比重裝用戶端快得多。