Clash 故障排查手冊

排查前準備:先固定變數,再動手

代理鏈路上的可變環節非常多:本地網路、用戶端、核心、配置檔案、訂閱、節點伺服器、目標網站,任何一環出問題表現都可能是「打不開網頁」。排查的第一原則是一次只改一個變數,否則問題消失了也不知道是哪一步起了作用,下次復發只能從頭再來。

動手前先記錄四項基礎資訊

• 用戶端與核心:用的是哪個用戶端(Clash Plus、Clash Verge Rev、FlClash 等),核心是 Meta/mihomo 還是原版。核心差異會直接決定某些配置欄位是否被識別,詳見部落格文章三種核心區別對比。
• 運行模式:目前是系統代理還是 TUN,分流模式是規則(Rule)、全域(Global)還是直連(Direct)。大量「時好時壞」的問題根源是模式選錯。
• 配置來源:訂閱連結匯入、本地 YAML 檔案,還是經過訂閱轉換服務處理過。轉換過的配置要額外考慮轉換範本引入的問題。
• 問題範圍:是所有網站都打不開,還是只有部分網站異常;是所有裝置都有問題,還是只有一台。範圍越清晰,後面能跳過的章節越多。

把日誌等級調到 debug

各用戶端都提供日誌面板,預設等級通常是 info,只記錄連線建立與規則命中。排查階段建議暫時調到 debug:DNS 查詢過程、規則逐條匹配、握手失敗原因都會印出來。本地配置檔案裡對應欄位:

log-level: debug   # 排查完記得改回 info,debug 日誌量很大

二分定位法

拿不準問題在哪一層時,按「代價從小到大」的順序逐層替換:先換節點(排除單節點故障)→ 再切全域模式(排除分流規則問題)→ 再換一份已知可用的配置(排除訂閱問題)→ 最後換用戶端或換網路環境(排除本機與本地網路問題)。每換一層測一次,問題在哪一層消失,故障就在哪一層。

↑ 回到目錄

無法上網:開啟代理後所有網站打不開

症狀定義:用戶端顯示已連線,但瀏覽器存取任何網站都失敗,包括原本直連就能打開的網站。這一類問題的關鍵是先分清「流量根本沒進代理」還是「進了代理但出口不通」,兩者的修法完全不同。

第一步:用 curl 直接測本地代理埠

繞過瀏覽器與系統代理設定,直接向本地埠發請求,可以立刻判斷核心本身是否工作:

# 測台灣本地可達地址(驗證核心與直連規則)
curl -I -x http://127.0.0.1:7890 https://www.baidu.com

# 測 204 探測地址(驗證代理出口)
curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204

結果分三種:兩條都通,說明核心正常,問題在系統代理層,直接跳到第 7 章;第一條通、第二條超時,說明直連正常但代理出口不通,跳到第 3 章排查節點;兩條都拒絕連線(connection refused),說明核心沒在監聽這個埠,繼續往下。

第二步:埠沒被監聽的三種原因

• 配置解析失敗,核心根本沒啟動。日誌裡會有 error 等級的 YAML 解析報錯,常見於手改配置時縮排錯位、或原版核心讀到了 Meta 專有欄位。修復配置或改用支援該語法的核心。
• 埠被其他程式佔用。日誌報 bind: address already in use。Windows 用 netstat -ano | findstr 7890、Linux/macOS 用 lsof -i :7890 找到佔用的行程,要麼結束它,要麼在配置裡改 mixed-port 後重啟。
• 埠只監聽了 IPv6 或防火牆攔截。檢查配置裡是否寫了非常規的 bind-address;Windows 首次執行時如果拒絕了防火牆授權彈窗,需要到「Windows 安全性中心 → 防火牆 → 允許應用程式通過防火牆」裡手動放行用戶端。

第三步:排查「關閉代理也上不了網」的殘留

用戶端異常退出(崩潰、被強制終止)時可能來不及還原系統代理,導致系統仍指向一個已經不存在的 127.0.0.1 埠,表現為「不開 Clash 反而沒網路」。修法:重新啟動用戶端並正常退出一次讓它還原設定;或手動清理——Windows 在「設定 → 網路和網際網路 → 代理」裡關閉手動代理,macOS 在「系統設定 → 網路 → 詳細資訊 → 代理」逐項取消勾選。TUN 模式異常退出偶爾會殘留虛擬網卡路由,重啟系統即可清空。

↑ 回到目錄

節點超時:延遲測試全部失敗或大面積飄紅

用戶端裡的延遲測試並不是 ping,而是透過該節點向一個探測 URL(通常是回傳 HTTP 204 的地址)發起完整請求並計時。因此「超時」意味著完整代理鏈路——本機 → 節點伺服器 → 探測地址——中至少一環斷了。

全部節點超時的排查順序

1. 先確認本地網路:關掉代理直接存取一個台灣本地網站。本地斷網時所有節點必然超時,這是最容易被忽略的一步。
2. 確認訂閱是否到期:服務商到期或流量用盡後,伺服端會拒絕驗證,所有節點同時超時是典型特徵。到服務商的用戶面板核對狀態,不要在用戶端裡空耗。
3. 核對系統時間:部分加密協定對時間偏差敏感,裝置時間與標準時間相差過大時握手會靜默失敗。手機與電腦都打開「自動設定時間」。
4. 換探測地址再測:探測 URL 本身被阻擋或抽風時,好節點也會顯示超時。在用戶端設定裡把測試地址換成另一個 204 端點再測一輪。
5. 更新訂閱:服務商更換了伺服器 IP 或連接埠後,舊配置裡的節點自然全部失效。手動更新訂閱抓取最新節點清單,更新失敗則轉第 4 章。

部分節點超時:正常現象與異常的分界

機場節點存在個別故障是常態,少數節點超時無需處理,切換到可用節點即可。需要警惕的是同一協定的節點集體超時——例如所有某種協定的節點全掛、其他協定正常,通常說明該協定特徵在目前網路環境被針對,短期內換協定使用,並回饋給服務商。另一種模式是「有線超時、熱點正常」或反之,指向本地網路對特定連接埠/協定的攔截,常見於公司、校園網路環境。

讀懂測試數值

還要注意:延遲低不等於速度快,延遲反映的是往返時間,頻寬是否充足要看第 5 章的測速方法。自動選擇群組(url-test)會按週期自動重測並切換,頻繁跳節點的問題也在第 5 章一併處理。

↑ 回到目錄

訂閱失敗:匯入報錯與更新失敗對照處理

訂閱問題分兩個階段:第一次匯入失敗,多半是格式問題;之前正常、某次更新開始失敗,多半是網路或伺服端問題。先看用戶端顯示什麼錯誤,再對號入座。

錯誤提示對照表

格式問題:先分清拿到的是什麼

Clash 用戶端只認 YAML 結構的配置,而市面上流通的訂閱還有 Base64 節點清單與各協定專用格式。把 Base64 訂閱直接餵給 Clash 用戶端,得到的就是「解析失敗」。區分方法很簡單:在瀏覽器裡打開訂閱連結,回傳內容以 proxies:、proxy-groups: 這類欄位開頭的是 Clash 格式;一大段無空格的字母數字是 Base64。格式差異與轉換原理在部落格文章Clash 訂閱格式詳解裡有完整展開,包括自建轉換服務的做法。

「時好時壞」的更新失敗

訂閱網域本身在部分網路環境下被干擾是常見情形,於是出現悖論:更新訂閱需要代理,代理配置又來自訂閱。多數用戶端提供「透過代理更新」開關,按目前狀態反著試:代理可用時開著更新,代理已失效時關掉直連更新。都失敗時,用手機流量開熱點給電腦更新一次,拿到可用配置先恢復代理,再切回正常網路。另外,部分用戶端支援設定訂閱自動更新間隔,設為每 12 或 24 小時一次即可,過於頻繁的自動更新在伺服端限流時反而容易觸發失敗。

↑ 回到目錄

速度慢:連得上但頻寬不達預期

速度問題的排查前提是建立基線:先關閉代理測一次本地裸速,再開代理測一次,兩者對比才有意義。本地裸速只有 50 Mbps 時,任何節點都不可能跑出 200 Mbps。

定位瓶頸在哪一段

1. 多換幾個不同地區的節點測速。所有節點都慢且慢得一致,瓶頸大概率在本地(路由器效能、電信業者國際出口、Wi-Fi 訊號);個別節點慢,是節點本身負載或線路問題,尖峰時段(晚間)尤其明顯。
2. 對比協定開銷。同一伺服器上,帶多層傳輸封裝的協定(如 WebSocket + TLS 組合)吞吐量低於輕量協定是正常物理開銷,不是故障。
3. 檢查是否套了雙重代理。瀏覽器外掛代理、系統裡殘留的其他 VPN 與 Clash 疊加時,流量繞兩圈,速度砍半起步。排查期間關掉所有其他代理工具。

分流失準導致的「假性慢」

台灣本地網站突然變慢,八成不是節點問題,而是這部分流量被錯誤地送進了代理。典型原因是 GeoIP/GeoSite 資料庫過舊,新增的本地網域與 IP 段不在庫裡,規則匹配不到只好走了兜底代理。判斷方法:開著代理存取台灣本地網站,在用戶端的連線面板裡看這條連線命中的是 DIRECT 還是代理群組。修復方法(更新 Geo 資料庫、驗證規則生效)在部落格文章GeoIP 與 GeoSite 資料庫更新方法裡有逐步說明。

自動選擇群組的參數調校

使用 url-test 自動選擇時,兩個參數直接影響體驗:interval 決定重測週期,tolerance 決定「新節點要比目前節點快多少毫秒才切換」。tolerance 不設或設得太小,會因為幾毫秒的抖動頻繁切換節點,每次切換都會斷開現有連線,體感就是「網速一陣一陣的」。參考寫法:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300      # 每 5 分鐘重測一次
    tolerance: 60      # 新節點需快 60ms 以上才切換
    proxies:
      - 節點A
      - 節點B
      - 節點C

↑ 回到目錄

DNS 問題:解析失敗、污染與 Fake-IP 副作用

DNS 是代理鏈路裡最隱蔽的一層:症狀經常表現為「部分網站打不開」「第一次打開很慢之後正常」「顯示的 IP 位址很奇怪」,而不會直接報 DNS 錯誤。理解 Clash 的兩種 DNS 增強模式是排查前提。

fake-ip 與 redir-host 的區別

fake-ip 模式下,核心對每個網域查詢立即回傳一個保留網段(預設 198.18.0.0/16)內的假 IP,真實解析推遲到流量實際發出時在鏈路遠端完成——延遲低、無污染,是目前主流用戶端的預設;代價是本機拿到的 IP 不是真實地址,少數依賴真實 IP 的程式(區域網路發現、部分遊戲連線、某些銀行用戶端)會異常。redir-host 則先在本地完成真實解析再匹配規則,相容性好但解析結果可能被污染。兩種模式沒有絕對優劣,按症狀切換。

典型症狀與修法

• 切換網路後大量網站打不開,重啟用戶端恢復:fake-ip 映射快取與新網路環境不一致。多數用戶端提供「清除 fake-ip 快取」按鈕,或直接重啟核心。
• 區域網路裝置(印表機、NAS)存取異常:區域網路網域被 fake-ip 接管了。在 fake-ip-filter 裡排除本地網域,見下方範例。
• 關閉代理後 DNS 仍異常:TUN 模式接管過系統 DNS,異常退出未還原。重啟系統網路服務或重啟裝置。
• 某些網域解析到明顯錯誤的地址:上游 DNS 被污染,把 nameserver 換成加密 DNS(DoH/DoT)。

一份可用的 DNS 配置基線

dns:
  enable: true
  listen: 0.0.0.0:53
  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://120.53.53.53/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

這份基線的思路:本地加密 DNS 做主解析保證速度,境外 DoH 做 fallback,fallback-filter 按 GeoIP 判斷解析結果歸屬——結果不在指定地區段時採用 fallback 的答案,規避污染。注意 fallback-filter 依賴 GeoIP 資料庫,庫過舊同樣會誤判,與第 5 章提到的 Geo 更新是同一件事。

↑ 回到目錄

系統代理不生效:瀏覽器正常但部分應用不走代理

症狀定義:用戶端運作正常、瀏覽器一切正常,但某些應用(命令列工具、商店應用、遊戲用戶端)的流量完全沒有經過代理。根源在於「系統代理」只是作業系統層面的一個建議值,應用可以讀也可以不讀,而不同類型的應用行為差異很大。

三類不讀系統代理的應用

命令列程式:環境變數寫法

# Windows PowerShell(目前工作階段有效)
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# Linux / macOS(寫入 shell 設定檔可持久化)
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 驗證
curl -I https://www.gstatic.com/generate_204

UWP 應用:解除回環限制

Windows 商店應用預設被禁止存取 127.0.0.1,系統代理指向本機連接埠時這類應用直接失聯。用系統管理員權限執行 CheckNetIsolation LoopbackExempt -a -n=<套件家族名稱> 逐個豁免,或用圖形化工具批量勾選。完整操作步驟、套件家族名稱查詢方法與驗證手段,見部落格文章Windows UWP 應用不走代理怎麼辦。

一勞永逸:TUN 模式

TUN 透過虛擬網卡在網路層接管全部流量,應用讀不讀系統代理都無所謂,是解決「部分應用不走代理」的根本手段。啟用要點:桌面端需要授予系統管理員/root 權限安裝虛擬網卡服務;啟用後建議同時開啟核心的 DNS 劫持,否則應用自行指定 DNS 時分流會失準;與其他 VPN 軟體的虛擬網卡互斥,同時只能開一個。Linux 環境下的 TUN 部署細節可參考部落格文章Linux 安裝 Clash 全流程。

↑ 回到目錄

用戶端崩潰:啟動失敗、閃退與資源異常

崩潰類問題先區分三種形態:一啟動就退出、運行中隨機閃退、以及沒退出但記憶體/CPU 占用異常。三者的排查入口不同。

一啟動就退出:幾乎都是配置問題

用戶端 GUI 啟動依賴核心成功載入配置,配置解析失敗時部分用戶端會直接退出而不是報錯。排查方法:先把配置目錄裡的活動配置換成一份最小可用配置(只留一個 DIRECT 規則),能正常啟動就證明是配置問題,再逐段加回內容定位出錯欄位。最常見的觸發點:

• YAML 縮排錯誤——手動編輯後多打或少打了空格,YAML 對縮排零容忍;
• 核心不匹配——配置裡用了 Meta/mihomo 專有欄位(如部分規則類型與出站協定),而用戶端跑的是原版核心。欄位支援範圍對照見核心區別對比;
• 規則集/Geo 資源下載不完整——首次啟動需要抓取外部資源,網路不通時部分核心會報錯退出,先直連網路完成初始化。

運行中隨機閃退

1. 查用戶端日誌與系統日誌:Windows 看事件檢視器的應用程式日誌,macOS 看主控台的崩潰報告,定位是 GUI 崩了還是核心崩了。GUI 崩、核心還活著(連接埠仍可 curl 通)時,多為介面層問題,重灌或換用戶端;核心崩則重點查配置與資源。
2. 排查超大訂閱:數千節點的訂閱在低規格裝置上解析與延遲測試時記憶體壓力很大,精簡訂閱或關閉自動測速後觀察。
3. 與安全軟體衝突:代理軟體的行為特徵容易被誤報,把用戶端目錄加入安全軟體白名單後複測。

記憶體/CPU 占用異常

連線數是佔用的第一影響因子:P2P 下載這類會瞬間打開數千連線的情境,記憶體上漲是正常現象,連線釋放後應回落。持續不回落時,檢查是否開啟了過密的自動測速(多個 url-test 群組 × 短 interval × 大量節點 = 持續的測試風暴),把 interval 放寬到 300 秒以上。桌面平台若長期駐留,優先選擇維護活躍的用戶端——各用戶端的維護狀態與資源佔用橫向對比見橫向評測頁,已停止維護的用戶端(如 Clash for Windows)遇到崩潰沒有修復管道,建議遷移到 Clash Plus 或 Clash Verge Rev。

↑ 回到目錄

Android 專項:背景被殺、VPN 衝突與系統設定干擾

Android 端的代理用戶端以系統 VpnService 形式運行,故障模式與桌面端有明顯差異:桌面端的問題多在配置層,Android 端的問題一半出在系統對背景服務的管控上。本章以 Clash Plus、Clash Meta for Android、FlClash 等用戶端的通用行為為準。

連線頻繁自動斷開:背景被系統回收

鎖屏一段時間後代理斷開、通知欄圖示消失,是國產 ROM 激進省電策略殺掉 VPN 服務的典型表現。逐項設定:

1. 系統設定 → 電池 → 找到用戶端 → 改為「不限制/允許背景執行」,關閉「自動管理」;
2. 最近任務畫面給用戶端上鎖(多數 ROM 支援下拉或長按鎖定),防止一鍵清理誤殺;
3. 系統設定 → 應用程式 → 用戶端 → 允許「自動啟動」與「關聯啟動」;
4. 在用戶端內開啟「開機自動啟動」並配合系統的 Always-on VPN(設定 → 網路 → VPN → 齒輪 → 永遠開啟的 VPN),被殺後系統會自動拉起。

VPN 通道衝突

Android 同一時刻只允許一個應用持有 VPN 通道。另一個 VPN 類應用(包括某些「加速器」「過濾廣告」類工具)啟動時,系統會靜默切斷 Clash 的通道,用戶端這邊只看到「連線斷開」。排查:設定 → 網路 → VPN 裡查看目前活躍的 VPN 是誰,停用衝突應用。同理,「私人 DNS」(Private DNS)設定為指定主機名稱時,DNS 查詢會繞開用戶端的 DNS 模組,導致分流失準,排查 DNS 類問題時先把私人 DNS 設為「自動」或「關閉」。

安裝與更新問題

• 提示「解析軟體包發生錯誤」:下載的 APK 與裝置架構不符。近幾年主流機型一律選 arm64-v8a 版本,極舊裝置才需要 armeabi-v7a,各架構安裝包在下載頁 Android 區按用戶端列出;下載中斷導致檔案不完整也會報同樣的錯誤,重新下載即可。
• 覆蓋安裝失敗:簽章不一致(例如從不同來源下載的同名應用)無法覆蓋,需先卸載再重新安裝。重新安裝前在用戶端裡匯出配置,避免訂閱遺失。
• 安裝後 VPN 授權彈窗沒出現:部分 ROM 會攔截授權彈窗,到系統 VPN 設定裡手動為該應用完成一次授權。

擷取日誌:adb logcat

介面上看不出原因時,用 adb 擷取執行日誌。電腦安裝平台工具並對手機開啟 USB 偵錯後:

# 只看錯誤等級輸出,觀察斷開瞬間的報錯
adb logcat *:E

# 按應用套件名稱過濾(套件名稱以實際安裝的用戶端為準)
adb shell pidof com.github.metacubex.clash.meta
adb logcat --pid <上一步輸出的行程編號>

日誌裡出現 VpnService revoked 說明通道被其他應用搶佔;出現記憶體相關的 kill 記錄則回到本章開頭處理省電策略。行動端如需系統化的初次配置流程,回到配置教學按步驟執行一遍,大部分「裝完就不對」的問題在教學主線裡已經規避。

↑ 回到目錄

沒有找到你的症狀?

本頁涵蓋的是有明確重現路徑的八類故障。如果問題不在其中:屬於「第一次配置就沒跑通」的,回到配置教學從頭核對;懷疑是用戶端本身能力限制的,對照橫向評測確認所用用戶端是否支援對應特性;需要更換或補裝用戶端的,前往下載頁——全平台首推 Clash Plus,Android 端另有 Clash Meta for Android 與 FlClash 可選。協定、核心、訂閱相關的背景知識與專題排查,持續更新在技術筆記。