為什麼「系統代理已開啟」不等於「所有流量都走代理」
Clash 用戶端的「系統代理」開關,本質是修改作業系統或桌面環境的代理設定項(Windows 的 WinINet 設定、macOS 的網路服務代理、Linux 的 GSettings 或環境變數)。這類設定只對主動讀取系統代理設定的程式生效,常見的是瀏覽器、部分 GUI 應用程式。它不是網路層的強制轉發,程式可以選擇忽略這個設定——這正是很多人遇到「代理明明開著,某個程式卻不走代理」的根本原因。
命令列工具(curl、wget、git、套件管理器等)大多不讀取系統代理設定,而是讀取環境變數(http_proxy、https_proxy、all_proxy)。這意味著系統代理開啟與終端能否走代理是兩件獨立的事,分別需要不同的排查思路。
如果需要不區分程式、統一按流量強制代理,唯一可靠的方式是 TUN 模式——它在網路介面層接管流量,不依賴應用程式是否主動讀取代理設定。本文後面會具體說明系統代理與 TUN 模式的取捨。
排查前先確認一件事:Clash 本身有沒有正常運作、有沒有可用節點。如果核心未啟動或訂閱節點全部失效,系統代理設定再正確也無法建立連線。這類問題建議先看運作日誌確認代理連接埠是否監聽正常。
瀏覽器不走代理的排查步驟
瀏覽器不走代理通常分為四類原因:代理開關未生效、瀏覽器有獨立代理設定、擴充功能或安全軟體攔截、DNS 未走代理導致的部分洩漏。按以下順序逐條排查。
第一步:確認系統代理開關狀態
打開 Clash 用戶端設定頁,確認「系統代理」處於開啟狀態,並核對監聽連接埠(通常是 HTTP/Mixed 連接埠,預設 7890 左右)。部分用戶端在切換設定檔後會重設該開關,升級或重新開機後也可能被系統恢復為關閉。
- Windows:打開「設定 → 網路和網際網路 → 代理」,確認「使用設定腳本」或「手動設定代理」是否指向本機位址與對應連接埠。
- macOS:打開「系統設定 → 網路 → 所選網路服務 → 詳細資訊 → 代理」,確認 Web 代理(HTTP)與安全網頁代理(HTTPS)均已勾選並填入正確連接埠。
- Linux(GNOME 等桌面環境):在「設定 → 網路 → 網路代理」中確認為「手動」模式,而非「自動」或「關閉」。
第二步:排除瀏覽器本身的獨立代理設定
部分瀏覽器(尤其是 Firefox)預設不跟隨系統代理,而是使用自己的連線設定。如果 Firefox 裡手動設定過代理或選擇了「不使用代理」,即使系統代理正常也不會生效。檢查路徑:
- Firefox:設定 → 一般 → 網路設定 → 確認選中「使用系統代理設定」。
- Chrome / Edge / 大多數基於 Chromium 的瀏覽器:預設跟隨系統代理,一般不需要單獨設定,但企業政策或某些擴充功能可能覆蓋這一行為,可在瀏覽器的代理設定頁確認是否被鎖定。
第三步:檢查擴充功能與安全軟體的攔截
廣告攔截類擴充功能、企業安全用戶端、部分 VPN 用戶端可能會強制修改網路請求路徑或劫持代理設定。可以先在瀏覽器的隱私/無痕模式下(預設停用擴充功能)測試是否恢復正常,如果恢復正常則說明問題出在某個擴充功能上,逐一停用排查即可定位。
第四步:確認 DNS 請求是否也走了代理
瀏覽器「能連上但很慢」或「部分網站正常、部分網站異常」,很多時候是 DNS 洩漏導致的——網頁資料走了代理,但域名解析走的是本機 DNS,被電信業者或本地網路提前干擾。這種情況不算嚴格意義上的「代理不生效」,但表現類似,建議同時檢查規則模式是否開啟了 DNS 劫持或 fake-ip 模式。
如果只想驗證代理鏈路本身是否通暢,建議直接存取 IP 查詢類頁面觀察出口 IP 是否變化,而不是先測試某個具體網站——具體網站異常可能是規則分流把它劃到了直連組,並不代表代理整體失效。
命令列終端不走代理的排查步驟
終端工具是否走代理,取決於該工具是否讀取代理環境變數,以及變數是否正確設定並被目前工作階段繼承。排查順序如下。
第一步:確認環境變數是否已設定
在 macOS / Linux 終端執行:
echo $http_proxy
echo $https_proxy
echo $all_proxy如果輸出為空,說明目前工作階段沒有代理環境變數,終端命令自然不會走代理。手動設定範例(連接埠需替換為用戶端實際監聽連接埠):
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"第二步:確認變數寫入了正確的設定檔
臨時用 export 設定的變數只在目前終端工作階段有效,新開的終端視窗不會繼承。如果需要長期生效,應寫入 shell 的啟動設定檔,例如 ~/.zshrc、~/.bashrc 或 ~/.bash_profile(具體取決於使用的 shell 和系統),修改後需要執行 source ~/.zshrc 或重新開啟終端才能生效。
第三步:確認工具本身是否讀取這些變數
不同工具遵循的規則不完全一致:
curl、wget:預設讀取http_proxy/https_proxy,大小寫通常不敏感但建議統一小寫。git:不自動讀取系統環境變數轉發,需要單獨設定git config --global http.proxy與https.proxy。- 套件管理器(如 npm、pip、apt):各自有獨立的代理設定項,環境變數未必被識別,通常需要在對應的設定檔裡單獨宣告代理位址。
- Docker、Docker Compose:容器內程式預設不共用主機的環境變數,需要在 Docker 設定或
docker-compose.yml中明確傳入代理變數,或者為 Docker daemon 單獨設定代理。
第四步:用最小化命令驗證代理鏈路
排除工具本身邏輯干擾,直接用 curl 測試代理連接埠是否真的可用:
curl -x http://127.0.0.1:7890 -I https://www.example.com如果這條命令能正常回傳回應標頭,說明代理連接埠本身運作正常,問題出在具體工具沒有正確讀取到代理設定;如果連這條命令都逾時或報錯,說明問題在 Clash 用戶端或節點本身,應回到用戶端檢查節點連通性與監聽連接埠。
建議把「用 curl 加 -x 參數手動指定代理測試」作為終端類問題的第一步驗證動作——它能快速把問題範圍縮小到「代理連接埠」還是「具體工具設定」兩者之一,避免在工具自身的複雜設定項裡繞圈子。
系統代理開關與 TUN 模式該怎麼選
系統代理和 TUN 模式是兩種覆蓋範圍完全不同的機制,選擇前建議先明確自己的需求場景。
系統代理開關的特點
系統代理只修改作業系統或瀏覽器讀取的代理設定項,優點是開銷小、切換靈活、對系統網路堆疊沒有侵入性;缺點是覆蓋不完整——任何不主動讀取系統代理設定的程式(部分命令列工具、遊戲、某些後台服務)都不會被代理覆蓋,需要額外手動設定環境變數或應用程式內代理選項。
TUN 模式的特點
TUN 模式會在系統中建立一個虛擬網路介面,由 Clash 核心接管經過該介面的全部流量,不區分應用程式是否主動設定代理。這意味著命令列工具、後台服務、遊戲等原本「不走系統代理」的流量也會被統一處理,更接近全域代理的效果。代價是設定項更複雜(通常需要額外開啟程式模式、處理路由表或防火牆規則),部分系統需要管理員/root 權限才能建立虛擬網卡。
兩種方式的取捨建議
- 只需要瀏覽器和常見桌面應用程式走代理:優先用系統代理開關,設定簡單,出問題也容易定位到具體軟體。
- 需要命令列工具、腳本任務、後台服務統一走代理,又不想逐一設定環境變數:優先考慮 TUN 模式,一次性覆蓋大部分場景。
- 同時需要精細的分流控制(某些程式直連、某些程式走代理):TUN 模式配合程式規則或 IP 段規則,比給每個工具單獨設定代理更省心,但需要花時間理解規則設定的寫法。
- 出現連線異常時,先確認目前用的是系統代理還是 TUN 模式,再針對性排查——兩者的故障現象和檢查路徑並不相同,混著排查容易走彎路。
如果開啟 TUN 模式後仍有部分流量繞過代理,通常是路由表或防火牆規則衝突導致,可先臨時關閉其他 VPN、網路加速類工具後重新測試,排除多個網路接管工具互相衝突的可能。
常見誤判場景與排查心態
系統代理相關問題裡,有幾類現象經常被誤判為「代理不生效」,實際原因並不在代理設定本身:
- 規則分流導致某網站走了直連:如果設定檔裡有針對特定域名或 IP 段的直連規則,該網站不經過代理是預期行為,不屬於故障。
- 節點本身連線異常:代理設定正確但節點失效,表現同樣是「網頁打不開」,需要先在用戶端裡單獨測試節點延遲與連通性。
- DNS 快取未刷新:切換代理或節點後,本機 DNS 快取可能仍指向舊的解析結果,建議排查前先清空系統 DNS 快取或重新啟動網路服務。
- 多個代理工具同時運作:如果同時開著其他代理軟體或 VPN,系統代理設定可能被後啟動的工具覆蓋,建議排查時先確認目前只有一個工具在修改網路設定。
整體的排查思路可以概括為:先確認 Clash 本身運作正常且節點可用,再確認系統代理開關或環境變數設定正確,最後確認具體應用程式是否遵循這些設定。按這個順序逐層驗證,能避免在錯誤的層級裡反覆調整而找不到問題根源。