故障排查 預計閱讀 9 分鐘

開了 Clash 瀏覽器還是直連?系統代理不生效的瀏覽器與終端分路排查

系統代理開關亮著,流量卻沒走代理——這類問題往往不是 Clash 本身的鍋,而是瀏覽器和終端各自維護了一套獨立的代理判斷邏輯。本文把排查拆成登錄檔/網路設定、瀏覽器外掛衝突、終端環境變數三條線,逐項定位,最後給出不依賴任何單一開關的 TUN 模式兜底方案。

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

Clash 客戶端介面上的「系統代理」開關,本質是在作業系統層面寫入一條 HTTP/HTTPS 代理設定——Windows 寫登錄檔裡的 ProxyServer 鍵值,macOS 寫網路服務的代理設定,Linux 桌面環境寫 GSettings 或環境變數。這條設定只對**遵守系統代理設定的程式**生效,而「遵守」與否完全由應用程式自己決定,作業系統並不會強制攔截所有出站連線去套用這條規則。

也就是說,系統代理是一份「建議」,不是強制轉發。主流瀏覽器(Chrome、Edge、Firefox 預設模式)會讀取這份建議,大多數命令列工具和部分老舊軟體則完全無視它,直接按自己的網路庫發起連線。這就是為什麼同一台電腦上,瀏覽器可能已經走了代理,終端裡 curl 卻還是直連失敗或直連成功但沒經過代理。

先分清兩種「不生效」 一種是代理設定根本沒寫進系統;另一種是設定寫進去了,但目標程式沒讀取它。前者要查系統設定和 Clash 核心狀態,後者要查具體程式的代理邏輯,兩條路完全不同,混著查只會越查越亂。

第一條線:系統層級登錄檔與網路設定

這是最基礎的一層,如果這一層沒配好,後面瀏覽器和終端的問題都無從談起。

Windows:檢查網際網路選項與登錄檔

打開系統代理開關後,Clash 會寫入目前使用者的 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings,關鍵欄位是 ProxyEnable(應為 1)和 ProxyServer(應指向 Clash 監聽的位址與埠,通常是 127.0.0.1:7890)。可以直接打開「設定 → 網路和網際網路 → 代理伺服器」,看手動代理設定是否與 Clash 的 HTTP 埠一致。

macOS:檢查網路服務的代理設定

macOS 的代理設定掛在每個網路服務(Wi-Fi、乙太網路等)下面,而不是全域唯一。打開「系統設定 → 網路 → 你正在使用的服務 → 詳細資訊 → 代理伺服器」,確認「網頁代理(HTTP)」和「安全網頁代理(HTTPS)」都已勾選,且位址埠指向 Clash 的本機監聽埠。多網卡、多網路服務時容易漏勾某一個,尤其是同時插了有線網路又開著 Wi-Fi 的情況,只改了一個服務的代理是白改。

常見坑 筆記型電腦切換 Wi-Fi 網路後,macOS 有時會把代理設定重置為「關閉」。如果發現代理時好時壞,先檢查是不是換了個 Wi-Fi 就被系統悄悄關掉了。

第二條線:瀏覽器為什麼不聽系統代理

瀏覽器不走代理,通常出現在以下四種情況,按排查優先級排列:

  1. 瀏覽器自身設定了獨立代理模式。 Firefox 預設不跟隨系統代理,而是走自己「網路設定」裡的手動設定,需要在 about:preferences 裡手動選擇「使用系統代理設定」,否則 Clash 怎麼開都跟它無關。
  2. 安裝了代理管理類擴充外掛。 SwitchyOmega 之類的擴充功能會接管瀏覽器的代理決策,即使系統代理已經指向 Clash,外掛裡如果設定的是「直接連線」或指向了別的位址,瀏覽器實際用的是外掛的設定,不是系統的。這是最容易被忽略的一類衝突,建議排查時先暫時停用所有代理類擴充功能,確認走不走代理,再決定是否要在外掛裡單獨設定。
  3. 瀏覽器內建了 VPN 或「安全瀏覽」之類的網路加速功能。 部分瀏覽器(尤其是部分中國大陸廠商的瀏覽器)自帶的網路加速開關會繞過系統代理直接發起連線,遇到怎麼設都不生效的情況,先在瀏覽器自身設定裡關掉這類功能。
  4. PAC 腳本模式設定錯誤。 如果 Clash 使用的是自動設定腳本(PAC)而不是固定的 HTTP 代理,瀏覽器需要能正常抓取到這個 PAC 檔案。可以直接在瀏覽器裡存取 PAC 位址(通常是 http://127.0.0.1:<埠>/proxy.pac),打不開說明 PAC 服務沒啟動,改用固定 HTTP 代理模式更穩。

排查順序建議:先用瀏覽器自帶的「網路診斷」或直接存取一個已知會被規則命中的網域,觀察 Clash 客戶端的連線面板裡是否出現這條記錄。出現了但是標著直連,說明規則或策略組的問題;完全沒出現,說明瀏覽器根本沒把請求送到 Clash,回頭查上面四條。

第三條線:終端為什麼不聽系統代理

終端環境是最容易被誤解的一塊——很多人以為開了系統代理,命令列工具就會自動跟著走,但 Linux 和 macOS 的終端工具鏈基本不讀取圖形介面的代理設定,它們看的是**環境變數**。

標準環境變數清單

大多數遵循 Unix 慣例的命令列工具(curl、wget、git、套件管理器等)會讀取以下環境變數:

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:7891"
export no_proxy="localhost,127.0.0.1,.local"

這幾行只在目前終端會話生效,關掉視窗就沒了。想要長期生效,需要寫進 ~/.zshrc、~/.bashrc 或對應 shell 的啟動腳本裡,並 source 一次讓它立即生效。Windows 的命令提示字元和 PowerShell 同理,可以用 $env:HTTP_PROXY、$env:HTTPS_PROXY 在目前會話設定,或者在系統環境變數裡長期寫入。

常見踩坑點

工具是否讀環境變數需要額外設定
curl / wget是無
git否(預設)http.proxy 設定項
npm / yarn否(預設)proxy / https-proxy 設定項
docker CLI是(需容器內單獨設定)容器環境變數或 daemon.json
Python requests是無(遵循標準環境變數)

TUN 模式:不依賴任何單一開關的兜底方案

如果按上面三條線逐項排查後還是有個別程式死活不走代理,或者根本不想再一個個設定環境變數和瀏覽器外掛,更徹底的做法是切換到 TUN 模式。TUN 模式在系統裡建立一個虛擬網卡,在網路層劫持全部出站流量,不再依賴應用層是否讀取系統代理設定或環境變數,理論上能覆蓋包括背景服務、遊戲客戶端在內的幾乎所有網路請求。

開啟 TUN 模式一般需要:客戶端具備管理員/root 權限運行,在設定裡啟用 tun 欄位,並確認 stack(如 gvisor 或 system)與本機網路環境相容。開啟後系統代理開關可以保持關閉狀態,因為流量已經在更底層被接管,兩者同時開啟通常不會衝突,但沒有必要疊加使用。

tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true
什麼時候該上 TUN 如果終端裡有多個自成一套網路邏輯的工具(比如某些 IDE 內建的套件管理器、遊戲更新器),逐個設定環境變數成本太高,直接開 TUN 模式一次性解決,比繼續在瀏覽器外掛和環境變數之間來回排查划算得多。

排查流程小結

遇到「系統代理開了但沒生效」的情況,建議按下面順序走一遍,而不是東一下西一下地試:

  1. 先看 Clash 客戶端的連線面板,確認對應請求有沒有出現——沒出現說明流量根本沒送到 Clash,先查系統代理設定寫沒寫對。
  2. 瀏覽器問題優先排查代理管理類擴充功能和瀏覽器自帶的網路加速功能,這兩項最容易被忽略。
  3. 終端問題先確認環境變數是否已在目前會話生效,再確認具體工具是否遵循環境變數還是需要獨立設定檔。
  4. 逐項排查成本過高、或者存在大量不遵循標準代理邏輯的程式時,直接切換 TUN 模式做兜底,不必糾結於逐個適配。

系統代理、瀏覽器外掛、環境變數、TUN 模式,本質上是四套互相獨立又可以疊加的流量接管方式,搞清楚目前問題出在哪一層,排查效率會比盲目重啟客戶端高得多。

下載Clash