Clash 系統代理無效排查:瀏覽器不走代理與終端機命令列不走代理分開處理

B-01先分清故障發生在哪一層

「Clash 打開了但沒生效」是一句模糊的描述,真正定位問題之前,必須先把「系統代理生效範圍」這張圖攤開看。Clash 客戶端在系統代理模式下,做的事情是修改作業系統的網路設定(Windows 的 網際網路選項 登錄項、macOS 的網路服務代理欄位),讓走系統代理協定堆疊的程式自動使用本機監聽埠(通常是 HTTP 代理 127.0.0.1:7890 或混合埠)。但作業系統的「系統代理」這個開關,只對遵守系統代理設定的程式生效,瀏覽器、終端機命令列、部分背景服務對它的遵守程度並不一致。

因此同一個「沒生效」的症狀,瀏覽器端與終端機端的排查思路完全不同,合併處理只會越改越亂。本文按「瀏覽器端—系統層—終端機端」三段分開給出檢查清單,末尾附驗證指令,建議按順序逐項核對,不要跳步。

B-02瀏覽器端排查:擴充功能衝突與內建代理設定優先順序

瀏覽器不走代理是最常見的回饋,原因集中在三處,按優先順序依次排查。

1. 瀏覽器安裝了代理管理類擴充功能

SwitchyOmega、Proxy SwitchySharp 一類擴充功能會接管瀏覽器的代理設定介面,一旦安裝並啟用,瀏覽器會優先聽從擴充功能的設定,而不是作業系統的系統代理。如果這類擴充功能目前處於「直連」或指向了另一個失效埠的設定,即便 Clash 已經把系統代理設好,瀏覽器依舊走不通。解決辦法是在擴充功能裡新增一條規則指向 Clash 的本機埠,或暫時停用擴充功能,觀察是否恢復正常。

2. 瀏覽器企業政策或歷史殘留設定

部分瀏覽器(尤其是企業環境預裝的版本)會被群組原則強制鎖定代理設定,系統代理的變更對它無效。可以在瀏覽器網址列存取內建的網路設定頁,確認代理來源顯示為「使用系統代理設定」而非「直接連線」或「手動設定」。如果發現是手動設定且指向舊位址,清除後重新啟動瀏覽器即可。

3. PAC 腳本模式下埠或規則寫反

Clash 客戶端部分版本支援透過 PAC(Proxy Auto-Config)腳本方式接管系統代理,如果 PAC 腳本裡的判斷邏輯有誤,或監聽埠與客戶端實際使用的埠不一致,瀏覽器請求 PAC 腳本得到的結果會是「直連」,表現出來就是完全不走代理。建議先切回標準的「系統代理」模式(非 PAC)排查一遍,確認問題是否隨之消失,再決定是否繼續使用 PAC。

B-03系統層排查:確認系統代理確實被寫入

瀏覽器排查無果之後,退一步確認「系統代理」這一層本身是否真的生效,而不是想當然地認為 Clash 開關打開了就一定寫入成功了。

Windows:核對網際網路選項

打開「控制台 → 網路和網際網路 → 網際網路選項 → 連線 → 區域網路設定」,確認「為 LAN 使用代理伺服器」已勾選,位址與埠與 Clash 客戶端設定介面顯示的一致。如果這裡是空的,說明客戶端的「設為系統代理」開關並未真正寫入成功,常見原因是客戶端權限不足(需要以系統管理員身分執行)或與其他代理軟體(如企業 VPN 客戶端)發生寫入衝突,後啟動的一方會覆蓋前者的設定。

macOS:核對網路服務的代理欄位

在「系統設定 → 網路 → 目前使用的網路服務 → 詳細資訊 → 代理伺服器」裡,檢查「網頁代理伺服器(HTTP)」與「安全網頁代理伺服器(HTTPS)」是否已勾選並填入 Clash 的監聽位址與埠。macOS 上如果同時有多個作用中的網路服務(例如乙太網路與 Wi-Fi 都在連線),Clash 只寫入了目前優先的那一個,而系統實際路由走的是另一個服務,也會造成「設定了卻沒生效」的假象,需要確認生效的網路服務與 Clash 寫入的是同一個。

B-04終端機命令列不走代理:環境變數才是關鍵

終端機(Terminal、PowerShell、Bash)裡的 curl、wget、git、npm、pip 等命令列工具,絕大多數不會讀取系統代理設定,而是各自讀取一套約定的環境變數,這是終端機不走代理最常被忽略的根本原因。系統代理寫入成功、瀏覽器也能正常上網,終端機依舊提示逾時或連線失敗,屬於完全正常的現象,不是故障,而是需要額外設定的一步。

需要手動設定的環境變數

大多數命令列工具遵循的是 http_proxy、https_proxy(以及大寫形式 HTTP_PROXY、HTTPS_PROXY)這兩個環境變數,值填入 Clash 客戶端的本機 HTTP 代理監聽位址。

macOS / Linux(Bash 或 Zsh),暫時生效,僅在目前終端機工作階段內有效:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

如果希望每次打開終端機都自動生效,把上面兩行加到 ~/.zshrc 或 ~/.bash_profile 末尾,儲存後執行 source ~/.zshrc 使其立即生效。

Windows PowerShell,暫時生效:

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

需要長期生效的情境,可以在 PowerShell 設定檔($PROFILE 指向的腳本)裡加入同樣兩行,或透過系統環境變數介面新增使用者層級變數。

部分工具有自己獨立的代理設定

git 即使設定了上述環境變數,某些版本仍需要額外設定才能對 HTTPS 協定的儲存庫生效:

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

npm 與 pip 同理,分別使用 npm config set proxy / npm config set https-proxy,以及在 pip install 時加上 --proxy 參數或在 pip.conf 裡設定。這類工具的獨立設定項優先順序高於環境變數,如果環境變數已經設定但工具依舊不走代理,先檢查該工具是否存在獨立的代理設定項並被覆蓋。

B-05用 TUN 模式繞開系統代理與環境變數的雙重設定

如果頻繁遇到某些程式既不遵守系統代理、也不讀取環境變數的情況(常見於部分 GUI 應用程式、遊戲客戶端、某些語言執行環境的網路函式庫),更省事的做法是切換到 TUN 模式。TUN 模式由 Clash Meta(mihomo 核心)及基於它的客戶端(Clash Verge Rev、FlClash 等)支援,原理是建立一張虛擬網卡接管系統全部出站流量,不依賴應用層是否讀取代理設定,瀏覽器與終端機命令列會同時生效,無需分別設定。

啟用 TUN 模式通常需要客戶端申請系統管理員/Root 權限來建立虛擬網卡,macOS 與部分 Linux 發行版可能需要額外安裝網路擴充套件,具體開啟步驟在各客戶端的「TUN 模式」或「Tun 網卡」設定項裡,開啟前建議先關閉系統代理選項,避免兩種接管方式疊加造成路由異常。

B-06逐項驗證:確認修復是否真的生效

改完設定不要憑「感覺能上網了」就下結論,用下面幾條指令逐一驗證,能明確區分是系統代理生效、終端機生效,還是仍未生效。

驗證終端機環境變數是否被讀取並成功走代理:

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

回傳 HTTP/1.1 204 No Content 說明代理埠本身運作正常。接著不帶 -x 參數、僅依賴已設定的環境變數再測一次:

curl https://www.gstatic.com/generate_204 -I

如果這一次也回傳 204,說明環境變數確實被 curl 讀取並生效;如果逾時或直接失敗,說明環境變數沒有正確匯出到目前工作階段,回頭檢查變數名稱大小寫與設定檔是否被正確載入。

驗證系統代理埠是否被系統正確註冊(Windows PowerShell):

netsh winhttp show proxy

該指令顯示的是 WinHTTP 層的代理設定,與瀏覽器使用的 WinINet 層設定可能不完全一致,如果兩者顯示的位址不同,通常也是瀏覽器不走代理的原因之一,需要在瀏覽器代理設定裡手動確認。

• 瀏覽器不走代理:先查擴充功能、再查內建代理來源、最後查 PAC 腳本是否寫錯。
• 系統代理開關打開卻無效:核對 Windows 網際網路選項 / macOS 網路服務代理欄位是否真的被寫入,以及是否存在多網路服務衝突。
• 終端機命令列不走代理:設定 http_proxy / https_proxy 環境變數,git、npm、pip 等工具需個別核對各自設定項。
• 反覆出現同類問題:考慮切換到 TUN 模式,一次性接管全域流量。