Clash 故障排除手冊

開始之前:排查思路與資訊收集

排查這件事,方法比運氣重要。這一章不解決任何具體問題,但它決定了你後面每一章能不能查得又快又準。花三分鐘讀完,能省掉後面反覆試錯的一小時。

三條排查原則

一次只改一個變數。很多人一出問題就同時換節點、換模式、重啟客戶端、重啟電腦,最後問題好了也不知道是哪一步起了作用,下次復發只能重新亂猜。正確做法是:改一處,驗證一次,記一筆。

從離自己最近的一端往外查。整條鏈路是「應用程式 → 系統代理 / TUN → 客戶端 → 節點 → 目標網站」,越靠左越容易自查,越靠右越依賴第三方。先確認本機這半段沒問題,再去懷疑節點和訂閱服務商,順序反了就是白忙。

每一步都要有驗證動作。「感覺好像好了」不算數,要有一個明確的驗證手段:一條 curl 指令、一次延遲測試、一個固定網站的存取結果。本手冊每章都會給出對應的驗證方法。

動手前先收集這幾樣資訊

• 客戶端名稱與所在平台(例如 Clash Plus / Windows、Clash Verge Rev / Linux),不同客戶端設定項位置不同,但排查邏輯通用;
• 目前的代理模式:規則 / 全域 / 直連,以及是否開了 TUN(虛擬網卡)模式;
• 訂閱來源:連結是訂閱服務商直接提供的,還是經過轉換服務處理過的;
• 客戶端日誌裡最近的錯誤行——幾乎每個客戶端都有日誌面板,先把等級調到 info 重現一次;
• 問題是「一直如此」還是「某次改動之後出現」。後者直接回滾那次改動,往往比排查快得多。

症狀速查表

不確定該看哪一章的,先對著下面這張表找症狀,點章節名稱直達。

症狀一:開了代理,完全無法上網

先給結論:這類問題九成出在兩處——流量根本沒進客戶端(系統代理沒設上、被別的軟體搶了),或者進了客戶端但出不去(模式選錯、規則命中攔截、節點全掛)。用一條指令就能把這兩類切開,別急著重裝。

第一步:用 curl 直接打客戶端埠

打開客戶端設定頁,記下混合埠(常見預設是 7890,但一定以你客戶端裡顯示的為準,別照抄網路教學)。然後在終端機 / 命令提示字元裡執行:

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

這條指令繞開系統代理,強制流量走客戶端埠。結果只有兩種走向:

• 返回 204 或任何 HTTP 回應標頭:客戶端和節點這半段是通的,問題出在「流量沒進來」——跳到下一小節查系統代理;
• 報連線被拒絕 / 逾時:流量進了客戶端但出不去,問題在客戶端設定或節點——跳到「流量出不去」小節。

流量沒進來:查系統代理與瀏覽器擴充功能

確認客戶端裡「系統代理」開關處於開啟狀態,再去系統設定裡核對代理確實被寫上了(各平台檢查位置見系統代理章的對照表)。寫上了還不行,重點排查三個「搶流量」的嫌疑對象:

• 瀏覽器代理擴充功能:SwitchyOmega 之類的擴充功能優先級高於系統代理,如果擴充功能裡設了一個已失效的代理,瀏覽器就全斷。把擴充功能切到「系統代理」或直接停用再試;
• 其他代理軟體殘留:之前安裝過的代理工具卸載不乾淨,退出時沒把系統代理還原,或者開機自動啟動後跟目前客戶端互相覆蓋。工作管理員裡搜一遍,把不用的徹底退出;
• 安全軟體與企業政策:部分安全軟體會鎖定代理設定,公司電腦可能有群組原則強制代理,這類環境需要先解除鎖定。

流量出不去:查模式與規則

1. 看代理模式。直連模式下所有流量都不走節點,誤開了就等於白開;新手誤觸這個開關的機率相當高。
2. 規則模式下,打開客戶端的連線 / 日誌面板,存取一次打不開的網站,看這條連線被哪條規則命中、分到了哪個策略組。命中 REJECT 就是規則把它攔了,命中的策略組裡如果選中的節點已失效,換一個節點即可。
3. 做一次「全域測試」:切到全域模式,手動選一個剛測過延遲正常的節點,再存取。全域能通、規則不通,基本可以鎖定是規則或策略組選擇的問題。

TUN 與系統代理疊加的陷阱

TUN 模式和系統代理同時開著,流量路徑會變得很難推理:有的連線走虛擬網卡,有的走系統代理,日誌看起來自相矛盾。排查期間只留一條通路——要麼關 TUN 只用系統代理,要麼開 TUN 關系統代理,定位到問題之後再恢復日常組合。

症狀二:節點延遲測試逾時

延遲列一片「逾時」確實嚇人,但先分清楚兩件事:延遲測試逾時不完全等於節點不能用。延遲測試是讓節點去存取一個固定的測試位址,個別節點對測試位址不友善但實際存取正常;反過來,也有延遲數字好看、真用起來打不開網頁的。最終以實際存取為準,延遲只是參考。

全部逾時:先查本地和訂閱,別怪節點

所有節點同時逾時,節點集體故障的機率反而最低,更可能是你這一側的問題:

1. 確認本地網路正常:關掉代理(或切直連模式),打開一個本地可直連的網站。本地都不通,先修本地網路,這不是客戶端的鍋;
2. 確認訂閱還活著:訂閱服務到期、流量用盡、或服務商重設了連結,都會讓整份節點集體失效。直連狀態下登入服務商官網核對狀態,然後在客戶端裡手動更新一次訂閱;
3. 檢查測試位址:部分客戶端允許自訂延遲測試 URL,如果被改成了一個本身就不可達的位址,那測出來自然全逾時。恢復成預設的 generate_204 類位址再測;
4. 換客戶端交叉驗證:同一份訂閱匯入另一個客戶端(取得客戶端頁五個平台都有備選),如果另一個客戶端一切正常,問題在原客戶端的設定,重點回查埠、TUN、DNS 三處。

部分逾時:節點端問題的判斷

只有部分節點逾時,處理起來反而簡單:

• 按區域成片逾時:某條國際線路故障或維護,換其他區域的節點先頂著,過幾個小時再回來看;
• 固定幾個節點長期逾時:大機率這幾個節點已下線但訂閱沒清理,回饋給訂閱服務商;
• 晚高峰集體變慢、偶發逾時:線路壅塞的典型表現,屬於速度緩慢那一章的範疇,換冷門區域節點緩解;
• 換了網路環境後成片逾時:某些網路(校園網路、企業網路)會攔截特定埠或協定,試試同一訂閱裡不同協定、不同埠的節點。

症狀三:訂閱匯入或更新失敗

訂閱問題的好處是報錯訊息通常很直白,壞處是很多客戶端把報錯折疊在日誌裡不彈出來。匯入 / 更新失敗後,第一件事是打開日誌面板找到那行紅字,然後對著下表按圖索驥。

報錯訊息對照

用指令手動驗證訂閱連結

拿不準是連結壞了還是客戶端的問題,用 curl 模擬客戶端拉一次訂閱(範例連結是假的,換成你自己的):

curl -A "clash" -I "https://example.com/api/sub?token=xxxx"

回傳 200 且回應標頭裡能看到 subscription-userinfo 之類的欄位,說明連結本身健康,問題在客戶端側;回傳 404 / 403,直接去服務商後台換新連結。注意 -A "clash" 這個參數:不少訂閱服務按 User-Agent 下發不同格式,瀏覽器直接打開看到的內容和客戶端拉到的可能不一樣,驗證時要帶上 clash 系 UA 才有參考價值。

匯入成功但節點清單是空的

這種「假成功」通常是格式問題:訂閱回傳的是通用分享格式而不是 Clash 設定,舊核心客戶端遇到新協定節點也可能整段跳過。兩個處理方向:一是找服務商要 Clash 格式的專用訂閱入口;二是確認你用的是 mihomo 核心的客戶端(取得客戶端頁在架的主力客戶端都是),新協定支援齊全,舊格式相容也更好。

更多訂閱相關的單點問答(自動更新間隔、多訂閱共存、流量資訊不顯示),集中在常見問題的「安裝設定」分類裡。

症狀四:能連上,但速度緩慢

「慢」是最難查的症狀,因為瓶頸可能在鏈路的任何一段。這一章的核心方法就一句話:先用交叉測試把瓶頸定位到某一段,再動手最佳化那一段,別一上來就換訂閱。

三段交叉定位法

1. 同節點測不同目標:目前節點下打開三四個不同的網站。全都慢,懷疑節點或本地;只有某個網站慢,那是目標站本身或它對這條線路不友善,換節點區域就好;
2. 同目標換不同節點:換兩三個不同區域的節點存取同一個網站。換誰都慢,重點查本地;換個區域就快,是原節點壅塞;
3. 直連測本地底速:切直連模式跑一次本地測速。直連都慢,先解決寬頻和 Wi-Fi 的問題,代理不可能比底速更快。

節點端:壅塞、倍率與協定

晚高峰變慢是共享線路的常態,冷門時段快、熱門時段慢,基本可以確認是壅塞,換冷門區域節點是最直接的緩解方式。另外留意訂閱裡的流量倍率標註——高倍率節點通常走更貴的線路,速度體驗往往也不同,值不值得用自己權衡。同一服務商如果提供多種協定入口,也可以互相切換對比,不同協定在不同網路環境下的表現差異不小。

客戶端端:模式與設定

• 日常用規則模式,別掛全域:全域模式下存取本地可直連的網站也要繞道節點,等於所有流量都排隊走窄門。規則模式讓直連流量走直連,是速度和體驗的最優解;
• 日誌等級調回 info:debug 等級會記錄海量日誌,長期開著對效能有拖累,排查完記得調回來;
• 檢查有沒有套了多層代理:策略組裡選了「中轉 / 鏈式」類分組,或者客戶端外面又套了一層別的代理工具,每多一跳都要付出速度代價;
• 規則集過大:自訂規則堆了幾萬條且寫法低效(大量正規表示式),比對開銷會上來,精簡規則或改用規則集(rule-provider)按需載入。

本機與網路環境端

Wi-Fi 訊號差、2.4G 頻段擁擠、路由器效能不足,都會成為整條鏈路的天花板。特別提一句在路由器上直跑核心的方案:軟路由 / 旁路由效能不夠時,跑代理的開銷會直接壓低全屋網速,選型思路見部落格路由器直跑 mihomo 核心部署概覽。此外看一眼有沒有下載工具、雲端硬碟同步在背景佔滿上傳頻寬——上傳一滿,所有連線的表現都會雪崩。

症狀五:DNS 解析異常

DNS 是最隱蔽的一類故障,症狀五花八門:節點延遲一切正常但網頁轉圈打不開、某些直連網站被解析到奇怪的地區、區域網路裝置突然找不到。如果你排除了節點和系統代理的問題還是不對勁,八成就是 DNS。

先搞懂 fake-ip 和 redir-host

Clash 系核心的 DNS 有兩種增強模式:fake-ip 給每個網域先回傳一個保留段的假 IP,連線進來後再按網域做規則比對,速度快、規則命中準,是目前的主流預設;redir-host 回傳真實解析結果,相容性場景下使用。兩者的詳細差異和適用場景,術語手冊裡有對應詞條,部落格的 DNS 設定詳解一文拆得更細,這裡只講排查。

典型症狀對照

• 網頁轉圈打不開,但節點延遲正常:多半是 nameserver 裡填的上游 DNS 不可用,解析這一步就卡死了。換成可達的 DoH 位址再試;
• 特定網站被解析到境外、載入異常:分流參考了 fallback 的境外解析結果,檢查 fallback-filter 是否設定了 geoip 兜底;
• 區域網路裝置、NAS、印表機找不到了:fake-ip 把區域網路網域也劫持了,把 *.lan、+.local 之類加進 fake-ip-filter;
• 關掉客戶端後一段時間上網仍異常:系統裡快取了 fake-ip 段的解析結果,清一次系統 DNS 快取即可恢復。

一份可直接套用的 DNS 段

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

思路很簡單:nameserver 負責日常解析,選直連可達、回應快的;fallback 負責兜底境外網域,配合 fallback-filter 的 geoip 規則——解析結果落在中國大陸 IP 就信 nameserver,否則採用 fallback 的結果,防止污染。

改完怎麼驗證

重新載入設定後,直接向客戶端的 DNS 監聽埠發一次查詢(對應上面設定的 1053 埠):

nslookup -port=1053 www.gstatic.com 127.0.0.1

fake-ip 模式下回傳 198.18 開頭的位址就是正常運作。另外記得清一次系統快取,別讓舊結果干擾判斷:

# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

症狀六:系統代理不生效

先講清楚原理,後面的怪現象就都能解釋了:客戶端開「系統代理」,本質只是在作業系統的網路設定裡登記一個 HTTP/SOCKS 代理位址,應用程式是否讀取這個登記,完全是自願的。瀏覽器讀,所以瀏覽器走代理;很多命令列工具和部分桌面應用程式不讀,所以它們照舊直連。這不是故障,是機制如此。

各平台檢查系統代理的位置

客戶端裡開關是開著的、系統設定裡卻是空的,說明寫入失敗了:檢查客戶端有沒有獲得修改網路設定的權限,以及是不是有別的軟體在反覆把它改回去(殘留的代理工具、某些安全軟體都幹這事)。Linux 桌面環境的坑更多一些,GNOME 和 KDE 各有一套代理設定,終端機還認環境變數,三套互不相通,部署細節可參考部落格Linux 兩條部署路線。

命令列與開發工具:要單獨餵

終端機裡的 curl、pip、npm 之類預設不讀系統代理,要靠環境變數(埠換成你客戶端的實際埠):

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

Git 則有自己的設定項,常用寫法是 git config --global http.proxy http://127.0.0.1:7890,不用了記得 --unset 掉。桌面應用程式裡如果有「網路設定」或「使用系統代理」的開關,優先在應用程式內打開,比全域折騰乾淨得多。

實在不想逐個設定:上 TUN 模式

TUN 模式建立一塊虛擬網卡,在網路層接管全部流量,不依賴任何應用程式配合,系統代理管不到的命令列、遊戲、UWP 應用程式統統能覆蓋。代價是需要管理員 / 系統擴充功能授權,並且 DNS 設定要正確(配合上一章的 fake-ip 方案)。開啟入口與授權步驟各客戶端不同,使用指南裡有對應小節;概念層面的解釋見術語手冊的 TUN 詞條。開 TUN 之後建議關掉系統代理,理由見症狀一裡說過的「只留一條通路」。

症狀七:客戶端當機或無法啟動

當機閃退看著嚇人,實際上是原因最集中的一類:設定檔語法錯誤和埠衝突,兩個加起來能覆蓋絕大多數案例。按下面的順序查,一般十分鐘內見分曉。

第一嫌疑:設定檔語法

客戶端剛匯入新訂閱、或你手動改過設定之後開始閃退,基本可以鎖定是設定問題。最乾淨的驗證方法是用核心直接做語法檢查——mihomo 核心自帶校驗參數(核心可在取得客戶端頁的核心區取得):

mihomo -t -f /path/to/config.yaml

有錯它會直接指出行號和原因。手動改設定最常見的三種低級錯誤:YAML 縮排用了 Tab 或層級不對、複製貼上帶進了中文引號、同一層級出現重複鍵。逐個對照改掉即可。改不明白就先換回上一份能用的設定,讓客戶端先跑起來。

第二嫌疑:埠衝突與殘留行程

上一個客戶端執行個體沒退乾淨、或別的軟體佔了同一埠,新執行個體起不來是必然的。先查誰佔著埠:

# Windows
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

找到佔用行程後,要麼結束它,要麼在客戶端設定裡換一組埠。順便檢查開機自動啟動項裡是不是躺著兩個代理客戶端在互相打架——只保留一個。

學會看日誌

以上都排除了還在崩,就得靠日誌說話。在架的主力客戶端(Clash Plus、Clash Verge Rev、FlClash 等)都提供日誌頁或「打開日誌目錄」入口。把日誌等級調到 debug,重現一次當機,看日誌最後幾行——當機前的最後一條記錄,通常就是元兇所在的模組。看不懂的報錯,拿關鍵詞搜常見問題的「故障排除」分類,常見報錯都收了詞條。

乾淨重裝的正確姿勢

1. 先備份:匯出或抄下訂閱連結,自訂規則和設定檔複製一份到別處;
2. 卸載並清殘留:卸載後手動刪掉設定目錄(位置見客戶端的「打開設定目錄」入口),殘留的壞設定是「重裝了還崩」的頭號原因;
3. 重裝並逐步恢復:先裝好、空設定能啟動,再匯入訂閱,再逐步加回自訂內容,每加一步驗證一次,壞東西自然會現形;
4. 換客戶端交叉驗證:同平台換一個客戶端(取得客戶端頁各平台都備了兩到四個選擇,首推 Clash Plus),同一份設定在別家也崩,那是設定問題;別家正常,再回頭深挖原客戶端。

症狀八:行動裝置專項(Android / iOS)

手機上的問題有自己的一套邏輯:桌面端的故障多在設定,行動裝置端的故障多在系統權限和背景策略。桌面思路照搬到手機上經常查錯方向,所以單獨成章。

Android:權限與背景是兩大命門

• VPN 權限:Android 客戶端靠 VpnService 接管流量,首次啟動的授權彈窗必須點允許。之後如果在系統設定裡撤銷了權限、或裝了另一個 VPN 類應用程式搶走了通道(系統同一時間只允許一個 VPN 活躍),客戶端就會靜默失效。設定 → 網路 → VPN 裡看一眼目前活躍的是誰;
• 電池最佳化砍背景:各家客製化系統的激進省電策略是「用著用著斷了」的最大元兇。把客戶端加入電池最佳化白名單、允許背景執行與自動啟動,部分系統還要在最近任務裡給它上鎖;
• 分應用程式代理設錯:客戶端裡的分應用程式代理(允許 / 排除清單)如果把目標應用程式排除了,那個應用程式自然不走代理。出問題先把分應用程式代理恢復預設再排查;
• 省流量模式與私人 DNS:系統的省流量模式會限制背景連網;系統層的「私人 DNS」設定也可能和客戶端 DNS 打架,排查期間設為自動。

Android 端在架客戶端(Clash Plus、Clash Meta for Android、FlClash、Surfboard)見取得客戶端頁 Android 區,同一訂閱換個客戶端交叉驗證的思路在手機上同樣好用。

iOS:圍繞 VPN 設定那點事

• 安裝管道:iOS 端從 App Store 安裝 Clash Plus 即可,入口在取得客戶端頁 iOS 區;
• VPN 設定衝突:裝過多個代理類應用程式的裝置,設定 → 一般 → VPN 與裝置管理裡會有多份 VPN 設定。切換應用程式前先把舊的斷開,兩份設定搶通道是 iOS 上「開了但沒流量」的常見原因;
• 切換網路後的短暫斷流:Wi-Fi 和行動網路之間切換時 VPN 通道要重建,幾秒鐘的斷流屬正常現象。頻繁掉線不恢復的,檢查客戶端裡的「按需連線 / 自動重連」設定是否開啟;
• 背景被系統回收:iOS 記憶體緊張時會回收背景應用程式,VPN 通道一般還在但應用程式介面要重新載入,重新打開應用程式即可,不算故障;
• 更新訂閱失敗:行動網路下留意系統是否禁了該應用程式使用行動數據(設定 → 行動網路裡逐應用程式開關)。

行動裝置通用建議

手機的網路環境比桌面複雜得多:Wi-Fi、行動網路、電信商 DNS、熱點各有各的脾氣。遇到「時好時壞」,先固定在同一個網路環境下重現,別在捷運裡邊切基地台邊排查。訂閱更新失敗時,把連結複製到瀏覽器驗證一下可達性(方法同訂閱失敗章),能快速區分是連結問題還是應用程式問題。系統的省電模式、低數據模式在兩個平台上都會干擾背景連網,排查期間統統關掉。