先確認現象:系統代理到底有沒有打開
「系統代理不生效」其實是一個模糊描述,背後可能是完全沒走代理、部分程式不走代理、或者走了代理但規則判錯了目標節點這三種不同問題。排查前先做一次基礎核對,能省掉大半排查時間。
打開客戶端主介面,確認左側或頂部的「系統代理」開關處於開啟狀態。這一步看起來多餘,但在實際支援記錄裡,相當一部分回饋最終都定位在開關被誤觸關閉,或者在系統重新啟動、客戶端更新之後系統代理設定沒有被重新寫入。
接著核對埠。Clash 核心預設會監聽一個 HTTP(或 HTTP+HTTPS 混合)埠和一個 SOCKS5 埠,常見預設值是 7890(HTTP)與 7891(SOCKS)。打開系統的網路代理設定面板,逐項核對位址與埠是否與客戶端設定頁顯示的一致——如果客戶端裡把埠改成了自訂值,而系統代理設定還停留在舊埠,流量自然打不進核心。
- 客戶端「系統代理」開關是否為開啟狀態;
- 客戶端顯示的混合埠/HTTP 埠/SOCKS 埠是否與系統代理設定一致;
- 是否存在多個代理工具同時搶佔系統代理設定,後啟動的覆蓋了前者;
- 節點分組目前選中的策略是否為「直連」或某個已失效的節點。
注意:部分客戶端在切換設定檔後會重置系統代理開關,更換訂閱或本地設定後建議重新確認一次開關狀態,不要憑記憶判斷。
瀏覽器端排查:代理開關、埠與擴充功能衝突
瀏覽器是最容易出現「看起來沒走代理」的場景,原因往往不在 Clash 本身,而在瀏覽器自身的網路設定層。不同瀏覽器對系統代理的採信方式並不完全一致,排查時建議按下面的順序逐步縮小範圍。
核對瀏覽器是否讀取系統代理
多數主流瀏覽器預設跟隨系統代理設定,但也有瀏覽器提供獨立的「內建代理」選項,一旦被啟用,就會忽略系統層的設定,轉而使用瀏覽器自己保存的位址。打開瀏覽器的網路/代理設定頁,確認代理模式為「使用系統代理」或「自動偵測」,而不是被切換成了「手動設定」卻填了一個過期的位址。
排查擴充功能帶來的衝突
瀏覽器擴充功能是另一個高頻雷區。部分翻牆類、廣告攔截類或隱私增強類擴充功能會自行接管代理設定或注入 PAC 腳本,與系統代理產生衝突,表現為「客戶端日誌裡完全沒有連線記錄」。建議暫時停用所有網路類擴充功能,重新整理頁面重新測試;如果恢復正常,再逐個啟用擴充功能定位具體衝突項。
用無痕視窗做對照測試
無痕/隱私視窗預設不載入一般擴充功能,是排查擴充功能衝突的便捷手段。如果無痕視窗裡代理正常而一般視窗不正常,基本可以確認問題出在擴充功能或瀏覽器本地快取的舊代理設定上,清空瀏覽器網路設定快取或重裝相關擴充功能即可解決。
提示:瀏覽器網址列輸入類似 about:net-internals 或對應瀏覽器的網路診斷頁面,部分瀏覽器會直接顯示目前生效的代理位址與埠,比反覆猜測更直接。
終端排查:環境變數、curl 測試與常見誤區
終端(命令列)程式通常不讀取系統級圖形代理設定,而是依賴環境變數。這也是很多人在瀏覽器代理正常、但 git、curl、npm 等命令列工具依舊連不上外網時感到困惑的原因。
先確認 Clash 客戶端是否開啟了對應平台的終端代理寫入功能(部分客戶端在系統代理開啟時會同步設定 http_proxy/https_proxy 環境變數,部分則需要手動設定)。可以直接在終端裡列印目前環境變數確認:
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:7891"設定完成後,用 curl 發起一次帶詳細資訊的請求,觀察是否真的經過了代理:
curl -v -x http://127.0.0.1:7890 https://example.org如果這條指令能正常回傳內容,而不帶 -x 參數的一般請求失敗或走向不同結果,說明代理鏈路本身沒問題,問題出在環境變數沒有被目標程式讀取上——常見原因是變數只在目前終端工作階段生效,新開的終端視窗或者由圖形介面啟動的程式(例如從桌面圖示而不是終端啟動的應用)根本不會繼承這些變數。將匯出語句寫入 shell 的啟動設定檔(如 .zshrc、.bashrc)並重新載入,或者在系統級環境變數裡統一設定,可以避免這種「時好時壞」的假象。
Windows 終端的額外一步
Windows 下的 PowerShell 和 CMD 同樣不會自動繼承圖形介面的系統代理設定,需要單獨設定工作階段變數或使用系統環境變數面板永久設定:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"設定後同樣用 curl.exe -v 或 Invoke-WebRequest 做一次驗證請求,避免僅憑「瀏覽器能用」就斷定終端也一定通。
繞過規則導致的假性失效
還有一類問題不是代理沒生效,而是代理生效了,但流量被規則判定為「應該直連」,於是表現得像完全沒走代理。這種情況最容易出現在設定檔裡的 rules 段或系統代理的繞過清單(bypass list)設定不當時。
系統代理設定裡通常會有一個「繞過以下位址」的輸入框,預設可能包含 localhost、內網位址段等,如果誤將測試用的目標網站或整個通配符加入了繞過清單,該位址就永遠不會經過代理,無論客戶端本身狀態如何。排查時建議先清空繞過清單做一次對照測試,確認問題是否消失。
設定檔層面的規則同樣值得核對。一份常見的規則片段如下,重點看是否存在過於寬泛的直連比對排在了前面:
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY如果測試目標恰好落在 GEOIP,CN,DIRECT 這類規則之前被命中,即使節點和埠全部正常,該請求也會被直接放行而不經過代理節點。可以打開客戶端日誌面板,切到詳細日誌等級,重新造訪一次目標位址,觀察這條連線命中的具體是哪一條規則、最終使用了哪個策略群組——這是判斷「規則誤判」還是「代理未生效」最直接的證據來源。
排查順序建議:先看日誌命中規則 → 再核對繞過清單 → 再檢查埠與開關 → 最後才懷疑節點本身是否可用,按這個順序定位效率最高,避免一上來就重裝客戶端或更換訂閱。
如果以上都正常,可以考慮 TUN 模式
系統代理依賴的是應用層協定(HTTP/SOCKS)轉發,部分程式不遵循系統代理設定、或者使用了自訂網路堆疊,天然不會經過系統代理,這類情況用系統代理模式很難徹底解決。如果反覆排查後確認代理鏈路本身沒問題,只是某些頑固程式繞開了系統代理層,可以考慮切換到 TUN 模式,由核心在網路層接管全部流量,不再依賴單個程式是否讀取代理設定。TUN 模式的接管範圍更徹底,但對權限與網路轉接器設定要求更高,建議在系統代理排查明確無效後再作為下一步方案,而不是一開始就跳過基礎排查直接開啟。