Clash 故障排查大全

通用排查思路與工具

Clash 的資料鏈路可以拆成四段:應用程式發出請求 → 系統代理或 TUN 把流量交給用戶端 → 用戶端按規則比對出站 → 節點把流量送到目標。任何一段斷掉,表現出來都是「上不了網」,但成因和修法完全不同。排查的核心動作只有一個:確認問題出在哪一段,然後只修那一段。

排查順序:從近到遠

固定按這個順序檢查,不要憑直覺跳步:先確認用戶端行程正在執行、設定已載入(介面上能看到節點清單);再確認流量確實進入了用戶端(連線面板裡有新增連線記錄);再確認規則比對符合預期(連線記錄裡的出站是你期望的策略群組);最後才懷疑節點本身。反過來查——一上來就換節點、換訂閱——是最常見的浪費時間方式,因為本機鏈路不通時換什麼節點都一樣。

日誌是第一手證據

所有 Clash 系用戶端都提供日誌面板,日誌詳細程度由設定檔的 log-level 欄位控制。排查期間建議暫時調到 debug,問題解決後改回 info,否則日誌量會非常龐大。

一條指令驗證代理鏈路

不依賴瀏覽器,直接用 curl 透過本機混合連接埠發一次請求,是判斷「用戶端到節點」這一段是否暢通的最快方式。回傳 204 或 200 即鏈路正常;卡住逾時代表節點不通;連線被拒絕代表本機連接埠沒有監聽。

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

如果你的混合連接埠不是預設的 7890,把指令中的連接埠號換成設定檔 mixed-port 的實際數值。這條指令繞過了系統代理設定,因此它的結果能把「系統代理沒設好」和「節點不通」兩類問題乾淨地分開:指令通、瀏覽器不通,查系統代理章節;指令也不通,查節點逾時章節。

縮小變數:一次只改一個條件

遇到不確定的問題,依序做三個對照實驗:換一個節點(排除單一節點故障)、切到全域模式(排除規則問題)、暫時退出其他代理/加速/安全類軟體(排除多個程式搶流量)。每次只改一個條件並記錄結果,三次實驗之後,問題範圍通常已經縮小到一個明確的章節。

開啟後完全無法上網

症狀定義:用戶端開啟後,所有網站(包括中國大陸網站)都無法開啟;或者關閉用戶端後網路恢復正常。這一類問題幾乎都出在本機鏈路,而不是節點。

第一步:確認實體網路本身正常

先完全退出用戶端(注意是結束行程,不是縮小到系統匣),然後開啟一個中國大陸網站。如果此時也開不了,問題與 Clash 無關,先解決本機網路;如果退出後能開啟、開啟用戶端後卻不能,繼續往下查。有一種例外情況需要留意:退出用戶端後仍然開不了任何網站——這通常是系統代理殘留,用戶端異常退出時來不及把系統代理設定改回去,處理方法見系統代理章節的「代理殘留」小節。

第二步:確認流量進入了用戶端

開啟用戶端的連線(Connections)面板,重新整理一次網頁,觀察是否出現新的連線記錄。有記錄代表系統代理這一段是通的,問題在後面;完全沒有記錄,代表流量根本沒走到 Clash——要麼系統代理沒寫入成功,要麼這個應用程式不遵循系統代理(典型如命令列程式),兩種情況都轉系統代理章節處理。

第三步:用全域模式做對照

把出站模式從「規則」切到「全域」,選一個先前測試可用的節點,再重新整理網頁。全域模式下能上網、規則模式下不能,代表問題在規則:大概率是規則集缺失導致大量請求落到了錯誤的出站,或者保底規則 MATCH 指向了一個不可用的策略群組。檢查設定檔末尾的保底規則,確認它指向的策略群組裡有可用節點:

rules:
  # ……前面是具體規則……
  - GEOIP,CN,DIRECT      # 中國大陸 IP 直連
  - MATCH,PROXY          # 其餘流量走 PROXY 策略群組(確認群組內有可用節點)

如果全域模式下也不能上網,規則可以排除,問題在節點或本機連接埠,轉節點逾時章節。

第四步:檢查中國大陸流量是否被錯誤代理

另一種「半癱」型態:海外網站能開、中國大陸網站反而開不了或極慢。這代表中國大陸流量也被送去了節點,而節點回中國大陸的鏈路品質差。檢查規則裡是否包含 GEOIP,CN,DIRECT 與常用中國大陸網域的直連規則;如果訂閱提供的設定缺這部分,可以自行在 rules 段靠前位置補上 DOMAIN-SUFFIX 直連條目。規則從上到下比對、命中即停,順序很重要——直連規則要放在保底 MATCH 之前。

節點全部逾時或延遲異常

症狀定義:延遲測試裡所有節點顯示逾時(timeout);或者節點顯示有延遲數值,但實際無法建立連線。先理解延遲測試在測什麼,再判斷問題層級。

延遲測試的原理與侷限

用戶端的延遲測試是透過每個節點向一個測試 URL(常見為 http://www.gstatic.com/generate_204)發一次 HTTP 請求,記錄完成耗時。它驗證的是「本機 → 節點 → 測試站」的完整鏈路,因此:全部逾時通常不是節點全掛了,而是本機到節點這一段被整體阻斷;個別逾時才更可能是那個節點自身的問題。另外要注意,延遲數值只反映一次小請求的來回耗時,和實際下載速度不是一回事——這個迷思在速度緩慢章節展開說明。

全部逾時:按序排除三個原因

其一,訂閱已失效。節點伺服器資訊(位址、連接埠、密碼)會由服務方輪換,本機設定停留在舊資訊就會全數失效。先手動更新一次訂閱,再重新測延遲;更新本身出現錯誤則轉訂閱失敗章節。

其二,本機網路封鎖了節點連接埠。公司、學校、飯店網路常見只放行 80/443 連接埠,節點若使用高位連接埠會全部不通。判斷方法:切換到手機熱點再測一次,熱點下全通而原網路全逾時,即可確認是網路環境限制,解決辦法是優先選用 443 連接埠的節點。

其三,系統時間偏差。部分加密協定對時間敏感,本機時鐘與真實時間偏差超過一定範圍(通常約 90 秒)會導致交握全部失敗,表現和節點全掛一模一樣。檢查系統時間是否開啟了自動同步,手動校正後重測。這是最容易被忽略、也最容易修的一個原因。

有延遲數值但連不上

延遲測試走 HTTP 小封包,實際業務可能走 UDP 或長連線,兩者通道不同。典型情境:網頁能開但語音/視訊通話不通——節點不支援 UDP 轉發。這屬於節點能力問題,換用標註支援 UDP 的節點即可,用戶端側無法修復。

讓自動選擇替你容錯

與其在節點故障時手動切換,不如用 url-test 類型的策略群組讓用戶端自動選擇目前最快節點、故障時自動切換:

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies: [節點A, 節點B, 節點C]
    url: http://www.gstatic.com/generate_204
    interval: 300        # 每 300 秒重測一次
    tolerance: 50        # 新舊節點延遲差小於 50ms 時不切換,避免頻繁抖動

訂閱更新失敗

症狀定義:點擊更新訂閱後出現錯誤,或長時間沒有回應。訂閱更新本質上就是用戶端對訂閱 URL 發一次 HTTP 請求並把回傳內容解析為設定檔,因此排查也分「請求失敗」和「解析失敗」兩類。

先讀錯誤訊息:常見錯誤對照

請求鏈路問題:先繞開用戶端驗證

用命令列直接請求訂閱網址,把用戶端因素排除在外:

curl -v -o sub.yaml "https://訂閱網址"

指令能正常下載而用戶端更新失敗,多半是用戶端的更新請求走了不可用的代理:很多用戶端預設「透過代理更新訂閱」,當節點全部失效時就會陷入「更新訂閱需要可用節點、取得可用節點需要更新訂閱」的死鎖。解決方法是在用戶端訂閱設定裡暫時改為「直連更新」,更新成功、節點恢復後再改回。首次匯入訂閱時同理——此時本機還沒有任何可用節點,必須允許直連請求。

指令也下載不了,則訂閱伺服器本身在目前網路下無法連線,與用戶端無關:換網路環境(如手機熱點)重試,或聯絡服務方確認訂閱網址是否已更換。

解析問題:回傳的不是設定

出現 YAML 解析錯誤時,用文字編輯器開啟上一步儲存的 sub.yaml 檢視內容:如果是一段 HTML(錯誤頁、驗證頁),代表訂閱伺服器把這次請求當成了瀏覽器造訪,或訂閱已失效;如果是 Base64 或其他編碼的節點清單而非完整 YAML,代表該訂閱格式面向的是其他核心,需要在取得訂閱時選擇「Clash 格式」,或使用服務方提供的格式轉換網址。

User-Agent 被伺服端區分對待

部分訂閱服務依請求的 User-Agent 回傳不同格式,甚至拒絕陌生的 UA。Clash Verge Rev、FlClash 等用戶端允許自訂訂閱請求的 UA,遇到 403 或格式不對時,嘗試把 UA 設為 clash 或服務方指定的值,往往能立刻解決。

能連上但速度緩慢

症狀定義:網路可用,但網頁載入緩慢、影片畫質上不去、下載速率遠低於預期。速度問題的變數最多,必須先建立基準,再逐項歸因。

第一步:建立本機頻寬基準

先關閉代理直連測一次本機頻寬,記下數值。代理後的速度不可能超過這個上限;如果直連本身只有 20 Mbps,那麼代理後 15 Mbps 已經是正常損耗,不必再折騰。基準之上,再比較不同節點的實際速度。

第二步:破除「延遲 = 速度」的迷思

延遲測試反映的是小封包來回時間,速度取決於節點的頻寬與承載人數。一個 60ms 的節點完全可能比 200ms 的節點慢得多——前者可能是公用的擁擠線路,後者可能是閒置的大頻寬線路。選節點看延遲只適合對互動敏感的情境(如遠端終端機);下載、影片類需求應實測傳輸量,方法是透過該節點實際下載一個大檔案觀察穩定速率。

第三步:檢查中國大陸流量是否繞行節點

規則缺失時,中國大陸網站流量出境後再折返,速度斷崖式下降且延遲翻倍。開啟連線面板,存取一個中國大陸網站,觀察這條連線的出站是否為 DIRECT。不是的話,補上直連規則:

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

注意 GEOIP 規則依賴本機 GeoIP 資料庫,用戶端一般會自動下載;若日誌提示資料庫缺失,在用戶端設定裡手動觸發一次資料庫更新。

第四步:高峰期與線路類型

晚間集體變慢、深夜恢復,是國際出口壅塞的典型特徵,屬於線路問題而非設定問題:換用不同落地區域的節點(如就近的港/日/新節點通常優於遠距離節點),或選擇服務方標註的優質線路。所有節點全天都慢,則回頭檢查是否有下載類軟體在背景佔滿上行頻寬,以及路由器上是否開著限速或 QoS 策略。

第五步:用戶端與核心層面的因素

仍在維護的用戶端(見選型指南)核心較新,對新協定與多工的支援更好;長期停留在停止維護的舊用戶端上,速度和相容性都會逐漸吃虧。另外,TUN 模式與系統代理模式在不同系統上的傳輸表現有差異,速度敏感的情境可以兩種模式各測一次,擇優使用。

DNS 相關問題

症狀定義:部分網站開不了而其他正常;網域解析到明顯錯誤的 IP;開啟 TUN 後所有網域解析失敗;或某些應用程式顯示的 IP 是 198.18.x.x 開頭的位址。這類問題都指向 DNS 設定。

理解 enhanced-mode:fake-ip 與 redir-host

Clash 的 DNS 模組有兩種運作方式。fake-ip 模式下,用戶端對每個網域先回傳一個 198.18.0.0/16 段的虛構 IP,讓應用程式立刻建立連線,真實解析推遲到流量出站時才進行——好處是解析零等待、網域資訊完整保留給規則比對;副作用是有些程式會把這個虛構 IP 快取或上報,產生困惑。redir-host 模式則老實解析出真實 IP。目前主流設定預設為 fake-ip,一般不需要改;看到 198.18.x.x 位址本身不是故障。

可直接套用的 dns 段範本

dns:
  enable: true
  listen: 0.0.0.0:53          # TUN 模式下建議監聽 53 連接埠
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"                  # 區域網路主機名稱不使用 fake-ip
    - "+.stun.*.*"             # STUN 探測需要真實 IP
    - "time.*.com"             # 時間同步類服務
  nameserver:                  # 常規解析:中國大陸 DoH,快且穩定
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:                    # 保底解析:境外 DoH,防污染
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN             # 解析結果為中國大陸 IP 時信任 nameserver,否則採用 fallback

各欄位的分工:nameserver 負責日常解析,選中國大陸 DoH 確保中國大陸網域解析又快又準;fallback 是並行的第二路解析,當 fallback-filter 判斷 nameserver 的結果可疑(例如境外網域卻解析出了異常結果)時採用 fallback 的答案,藉此對抗解析污染。逐項原理與更多寫法見部落格《Clash DNS 設定逐項拆解》。

典型故障與對症處理

個別網站開不了、其餘正常:在連線面板搜尋該網域,看它的解析與出站是否符合預期;若網域被錯誤直連且解析結果異常,為它補一條走代理的網域規則(DOMAIN-SUFFIX,example.com,PROXY)通常即可解決。

開啟 TUN 後解析全部失敗:TUN 模式會把系統 DNS 請求也接進用戶端,此時 dns 段必須 enable: true 且監聽 53 連接埠(如上範本),否則系統發出的解析請求無處回應。檢查用戶端 TUN 設定裡的「DNS 劫持」選項是否開啟,設定檔方式則確認 listen: 0.0.0.0:53 存在。

區域網路裝置(印表機、NAS)存取異常:區域網路主機名稱被 fake-ip 接管所致,把對應網域樣式加進 fake-ip-filter,如範本中的 *.lan。

遊戲或通話類應用程式行為異常:這類應用程式常用 STUN 探測公用網路位址,fake-ip 會干擾探測,範本中 +.stun.*.* 一類的過濾條目就是為此準備的,按應用程式實際使用的探測網域補上即可。

系統代理不生效

症狀定義:用戶端運作正常、第 1 章的 curl 驗證指令能通,但瀏覽器或某些應用程式的流量就是不走 Clash;或用戶端退出後系統仍處於代理狀態。

確認系統代理是否寫入

用戶端的「系統代理」開關做的事情,是把 127.0.0.1:7890 寫進作業系統的代理設定。開關打開後,到系統裡親眼確認一次:

開關開了但系統裡沒寫入:檢查是否有其他軟體(瀏覽器代理擴充功能、加速器、另一個代理用戶端)在反向覆蓋設定;macOS 上還要注意代理寫入的是「目前作用中的網路服務」,連接了多個網路卡時可能寫到了另一張網路卡上。

不吃系統代理的應用程式:環境變數與 TUN

系統代理只是一個「建議」,應用程式可以不理會。命令列工具(git、套件管理器、各類 SDK)大多預設忽略系統代理,需要明確設定環境變數:

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

這條指令只對目前終端機工作階段生效,適合臨時使用;需要長期生效可寫入 shell 的設定檔。而對於既不認系統代理也沒有代理設定項的應用程式,根治方案是 TUN 模式:用戶端建立一張虛擬網路卡,在網路層接管全部流量,任何應用程式都繞不開。設定檔方式開啟:

tun:
  enable: true
  stack: system          # 相容性問題多時可改 gvisor 對照測試
  auto-route: true       # 自動接管路由
  auto-detect-interface: true

注意 TUN 需要管理員/root 權限,並要求 DNS 段按上一章範本正確設定;主流用戶端(Clash Plus、Clash Verge Rev、FlClash)在設定介面都提供了 TUN 開關與所需的權限引導,優先用介面開關而不是手動改設定。

代理殘留:退出後仍無法上網

用戶端被強制結束(當機、工作管理員結束處理程序、系統斷電)時,來不及恢復系統代理設定,重新開機後瀏覽器仍嘗試連接已不存在的 127.0.0.1:7890,表現為「什麼都開不了」。修復方法:按上表位置進入系統代理設定,手動關閉代理;或重新啟動一次用戶端、正常退出,讓它自己收回設定。日常養成從系統匣選單正常退出的習慣即可避免。

用戶端啟動失敗與當機

症狀定義:雙擊無反應、啟動即閃退、核心反覆重啟、或日誌停在某條錯誤上。這類問題的錯誤訊息指向性很強,優先把日誌裡的原話找出來。

連接埠被佔用:bind: address already in use

啟動日誌出現 bind: address already in use,代表設定要監聽的連接埠(常見 7890/7891/9090)已被其他處理程序佔用——可能是上一次沒退乾淨的舊核心,也可能是別的軟體。三平台定位指令:

佔用者是殘留的舊核心,結束它即可;是其他常駐軟體,則改自己這邊的連接埠更省事——在設定檔裡換一個不衝突的連接埠:

mixed-port: 7893           # HTTP 與 SOCKS5 共用的混合連接埠
external-controller: 127.0.0.1:9097   # 控制介面連接埠一併避開衝突

改完連接埠後,記得系統代理與環境變數裡的連接埠號同步更新。完整的逐步操作見部落格《Clash 提示連接埠被佔用怎麼辦》。

設定檔語法錯誤

日誌出現 yaml: line N: 一類錯誤,代表設定檔在第 N 行附近有語法問題。YAML 對格式極其敏感,三個高頻錯誤:用了 Tab 縮排(必須用空格)、冒號後面漏了空格(port:7890 錯,port: 7890 對)、包含特殊字元的字串沒加引號(節點名稱含 @、# 等字元時要用引號包住)。手動編輯過設定的,按錯誤行號逐一核對;訂閱下發的設定出錯,先重新更新訂閱覆蓋本機修改。

權限不足

開啟 TUN 或監聽低位連接埠(如 DNS 的 53)需要提升權限:Windows 上按右鍵以系統管理員身分執行,或使用用戶端提供的服務模式;macOS 上按用戶端提示完成授權;Linux 上給核心檔案授予能力位(setcap cap_net_admin,cap_net_bind_service=+ep)或以 systemd 服務方式執行。日誌中出現 operation not permitted 即屬此類。

乾淨重裝:最後的保底方案

反覆當機且日誌無明確指向時,做一次乾淨重裝:匯出訂閱網址備份 → 卸載用戶端 → 手動刪除殘留的設定目錄(各用戶端資料目錄位置見其設定頁「開啟設定目錄」入口)→ 從下載頁重新安裝目前維護中的版本 → 重新匯入訂閱。注意舊設定目錄不刪,重裝往往等於沒裝,問題會原樣回來。仍在使用已停止維護的用戶端(如 Clash for Windows)且頻繁當機的,建議直接換用維護中的用戶端,遷移對照見選型指南。

行動裝置專項(Android / iOS)

行動系統對背景處理程序與網路介面的管控遠嚴於桌面,很多「桌面上從沒見過」的問題都源於此。本章按平台分列。

Android:VPN 授權與背景存活

Android 上的 Clash 用戶端(首選 Clash Plus,其餘見下載頁 Android 區)透過系統 VPN 介面接管流量,第一次啟動必須同意「建立 VPN 連線」的系統彈出視窗;誤點拒絕後用戶端只能空轉,到系統設定 → 應用程式 → 該應用程式 → 權限裡無法找回,需在系統「VPN」設定項裡重新發起連線授權。狀態列沒有鑰匙圖示,就代表 VPN 通道沒有建立。

第二大類問題是背景被清除:鎖定畫面一段時間後網路斷線、回到應用程式發現核心已停止,是系統電池最佳化把處理程序清除了。處理三件事:在系統電池設定裡把該應用程式設為「不受限制/允許背景執行」;在最近工作裡鎖定該應用程式;各品牌自訂系統(MIUI、ColorOS、HarmonyOS 等)還需在各自的「自動啟動管理」裡放行。三處都設定後,背景存活率會顯著改善。

此外,Android 用戶端普遍支援「分應用程式代理」:只讓指定應用程式走代理,或排除指定應用程式。銀行類應用程式對代理敏感時,把它加入排除清單即可共存,不必整機關閉代理。

Android:設定與訂閱的差異點

行動裝置更新訂閱同樣受「經代理更新」死鎖影響(見訂閱失敗章節);流量敏感使用者注意自動更新間隔,訂閱檔案本身不大,但頻繁的背景延遲測試會產生持續的小流量。多裝置之間保持設定一致的幾種做法,見部落格《Clash 多裝置設定同步方案比較》。

iOS:安裝管道與常見問題

iOS 側透過 App Store 安裝 Clash Plus(官網 clashplus.io,商店連結見下載頁 iOS 區)。安裝後第一次啟動同樣需要在系統彈出視窗中允許新增 VPN 設定,對應的設定會出現在系統設定 → 一般 → VPN 與裝置管理中。常見問題兩類:一是開關開啟後立刻跳回——多為訂閱未匯入或設定無可用節點,先在應用程式內確認節點清單非空、延遲測試有結果,再開啟連線;二是切換 Wi-Fi 與行動網路後短暫斷線——屬於系統網路切換時 VPN 通道重建的正常過程,數秒內自動恢復,持續無法恢復時在應用程式內手動重新連線一次。

iOS 系統限制單一時刻只能有一個作用中的 VPN 設定,裝有多個代理類應用程式時互相取代是預期行為,保留一個常用的即可。另外,iOS 應用程式在背景被系統回收後,VPN 通道由系統網路擴充功能維持,正常情況下不影響連線;若頻繁斷線,優先檢查訂閱有效性與節點品質,而不是反覆重新安裝應用程式。

行動裝置通用自我檢查清單

1. 狀態列是否有 VPN 圖示(Android 鑰匙 / iOS「VPN」標識)——沒有則通道未建立,回到授權環節。
2. 應用程式內延遲測試是否有可用節點——全逾時按節點逾時章節處理,行動網路與 Wi-Fi 各測一次以區分網路環境因素。
3. 訂閱最近一次更新是否成功——失敗按訂閱失敗章節處理。
4. 問題是否只出現在特定應用程式——是則考慮分應用程式代理清單與該應用程式自身的網路策略。

仍未解決時的建議路線

按本頁流程走完仍未定位的問題,通常剩下三種可能。其一,問題在服務端:訂閱服務的節點、線路、額度狀態只有服務方能確認,帶著你在排查中收集的證據(錯誤原話、哪些節點通哪些不通、什麼時間開始)去詢問,溝通效率遠高於一句「用不了」。其二,問題在用戶端實作:同一份訂閱換一個維護中的用戶端交叉驗證,若新用戶端一切正常,按選型指南完成遷移即可,不必戀戰。其三,問題在基礎環節的疏漏:回到使用文件把主線流程重新走一遍,大量「查了很久的怪問題」最終被證明是某個基礎開關沒有打開。

最後,保持用戶端與訂閱的更新習慣、優先使用維護中的用戶端、把常用出站交給 url-test 自動選擇——這三件事能預防本頁七成以上的故障。工具的價值在於穩定可預期,設定一次、長期安靜地運作,才是排查的最終目標。