Clash 故障排除大全

通用排查流程:先定位故障出在哪一層

「不能用」三個字的資訊量太低。Clash 處理一條網路請求要經過四個環節:用戶端與核心負責收發流量,系統代理決定哪些流量能進來,節點鏈路負責把流量送出境,規則與 DNS 決定每條連線具體怎麼走。任何一環斷掉,瀏覽器看到的都是同一個「無法連線」。排查的意義就是把故障釘到具體某一層再對症下藥——層級判斷錯了,換十個機場也解決不了系統代理沒寫進去的問題。

第一層驗證:日誌與埠

打開用戶端的日誌頁,等級調到 info。核心正常時能看到設定載入與埠監聽的紀錄;日誌一片空白或反覆刷錯誤,說明問題出在用戶端本身,直接去第八章。日誌裡幾類關鍵字值得記住:bind 相關多為埠被佔用,parse 相關是設定解析失敗,dial 相關是節點連線失敗。再用一條指令驗證埠是否在聽:

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

回傳 HTTP 204 說明用戶端、節點、規則整條鏈路是通的,故障在系統代理或瀏覽器層;逾時或拒絕連線,則繼續往下查節點與規則。這條指令是全手冊複用率最高的一步,建議記牢。

這條指令還有幾個值得記住的變體:把埠換成 7891 可以單獨驗證 SOCKS5 埠;把 -I 換成 -v 能看到完整的交握與回應標頭,TLS 在哪一步斷掉一目瞭然;把目標位址換成一個純 IP 的 HTTP 網站,可以繞開 DNS 單獨驗證轉發鏈路。建議把這條指令連同自己用戶端的實際埠一起記在筆記裡——排查任何「連不上」類問題,它都是第一塊試金石。

如果 curl 直接提示「無法連線到 127.0.0.1」,說明用戶端的代理埠根本沒有在監聽:先確認用戶端主介面顯示的混合埠是多少(不一定是預設的 7890),再確認核心程序是否真的活著——工作管理員或活動監視器裡找一下核心程序名,找不到就回到第八章處理啟動問題。

二分排除法

三步把問題圈定到最小範圍:換節點(排除單節點故障)→ 換網路(切手機熱點,排除本地寬頻阻斷)→ 換裝置(手機匯入同一訂閱,排除本機環境問題)。每步只改一個變數,結果立刻可讀。三步全部做完,故障點基本只剩一個候選。

症狀速查表

不想讀流程的,直接按症狀跳章節:

無法上網:代理已開但網頁打不開

最高頻的症狀。用戶端開關都開了,瀏覽器卻全部逾時。按下面的順序走,每一步都有明確的「通過 / 不通過」標準,不要跳步。

第一步:驗證用戶端到節點的鏈路

用上一章的 curl 指令驗證。通過,說明用戶端、節點、規則都沒問題,直接跳到第三步查系統代理;不通過,繼續第二步。

第二步:檢查代理模式與節點

用戶端一般有三種模式:全局(所有流量走代理)、規則(按規則分流)、直連(全部不走代理)。誤觸「直連」的表現就是「開了等於沒開」。先切到全局模式再測:全局能開網頁,說明鏈路正常,是規則把目標站分流到了直連或失效的節點群組,回頭整理規則與策略群組;全局也不行,換一個節點再測,全部節點都不行就按第三章處理。

第三步:檢查系統代理是否真正寫入

Windows:設定 → 網路和網際網路 → 代理伺服器,「使用 Proxy 伺服器」應處於開啟狀態,位址 127.0.0.1,埠與用戶端混合埠一致(預設 7890)。被安全軟體或類似工具改回去的情況很常見。macOS:系統設定 → 網路 → 目前網卡 → 詳細資訊 → 代理伺服器,確認網頁代理伺服器與安全網頁代理伺服器的勾選狀態和埠。這一項的深入排查見第七章。

第四步:防火牆與安全軟體

Windows 防火牆或第三方防毒軟體可能攔截核心程序連網:首次啟動時彈出的「允許存取」如果點了拒絕,用戶端看起來在跑、實際一個封包都出不去。在防火牆允許清單裡放行用戶端與核心程序,或者重新安裝一次用戶端並在彈窗時點允許。

macOS 上也有同類問題:系統防火牆開啟「阻斷所有傳入連線」時,部分用戶端的本機埠會被一併攔掉;企業裝置上的 MDM 描述檔可能直接鎖定代理設定,一般使用者改不動。Linux 桌面使用者則要留意發行版內建的防火牆(如 ufw、firewalld)是否放行了本機回環流量——回環介面預設放行,但被自訂規則改寫過的環境需要手動確認。

第五步:瀏覽器自身的代理與擴充功能

系統代理確認無誤之後,問題可能還在瀏覽器內部。代理切換類擴充功能(SwitchyOmega 等)會覆蓋系統設定,先停用再測;瀏覽器的「安全 DNS」功能會讓網域解析繞過用戶端,表現為「能連但內容不對」;個別瀏覽器支援獨立的代理設定,檢查是否被設成了「不使用代理」。換一個從未裝過擴充功能的瀏覽器(或開訪客視窗)測一次,是最快的排除法。

第六步:換網路環境交叉驗證

以上全部正常卻仍打不開網頁時,把電腦切到手機熱點再測一次。熱點下立刻恢復,說明故障在本地寬頻或路由層:部分路由器韌體會攔截非常用埠的出站連線,電信業者也可能對代理流量做定向干擾。此時優先換協議特徵不同的節點,或開啟 TUN 模式繞開應用層的種種限制。

節點超時:延遲測試一片 Timeout

延遲測試全紅先別慌,「全滅」和「個別逾時」是兩種完全不同的故障,處理路徑也完全不同。

全滅:問題在本地或訂閱

所有節點同時 Timeout,大概率不是節點集體當機,而是:本地網路阻斷(寬頻、校園網、公司網對代理埠的封鎖)、套餐到期或流量用盡、系統時間錯誤。先切手機熱點測一次:熱點下全部恢復,就是本地寬頻的問題,換協議類型(如從 Trojan 換 Hysteria2)或換埠特徵不同的節點。

系統時間偏差是隱形殺手

Trojan、VLESS、Hysteria 等協議都建立在 TLS 之上,交握時會驗證憑證有效期。系統時間與真實時間差幾分鐘,所有 TLS 節點會集體交握失敗,表現與節點全滅一模一樣。校準指令:

# Windows(系統管理員終端機)
w32tm /resync

# macOS
sudo sntp -sS time.apple.com

# Linux
timedatectl set-ntp true

校準後重新啟動用戶端再測。長期不連網對時的裝置(軟路由、長期關機的舊機器)尤其容易踩到這一條。

個別逾時:節點自身問題

只有部分節點逾時,通常是節點當機、被電信業者針對性阻斷,或該節點的協議特徵被本地網路識別。直接換節點;同一地區全部逾時再換地區。注意延遲測試的原理:用戶端向測試 URL 發起一次 HTTPS 請求並計時,不是 ICMP ping——測試位址本身無法連線時也會顯示 Timeout,可以在設定裡把測試 URL 換成更穩定的位址再確認一次。

套餐與訂閱狀態

機場套餐到期、流量耗盡時,訂閱連結還在、節點清單也還在,但全部不可用。登入機場後台確認套餐狀態;部分用戶端能顯示訂閱回傳的流量資訊標頭,順便核對。訂閱本身更新不了的情況看第四章。

延遲測試本身的誤報

延遲測試依賴用戶端內建的測試位址(通常是某個 generate_204 端點)。測試位址被本地網路阻斷時,所有節點都會顯示 Timeout,但節點其實是通的——直接開全域模式存取一個境外網站驗證,能打開就說明是測試誤報。在用戶端設定裡把延遲測試 URL 換成另一個穩定位址,或把逾時閾值從預設的 3 秒放寬到 5 秒,都能減少這類誤報。高丟包線路上,UDP 類協議(Hysteria2、TUIC)的延遲測試也可能偶發逾時,多測兩次再下結論。

訂閱失敗:更新訂閱報錯

「更新失敗」只是外殼,用戶端一般會附帶更具體的原因:網路錯誤(timeout、connection refused)、解析失敗(yaml、base64)、HTTP 狀態碼(403、404)。先把錯誤訊息讀全,再對號入座。

驗證訂閱連結本身

把訂閱連結原樣貼進瀏覽器網址列:能下載到一個文字檔,說明連結有效;403 多為 token 失效或套餐到期,404 是連結拼錯或訂閱被重置。手動複製容易漏字元、帶空格,從機場後台重新複製完整連結。典型的訂閱連結長這樣:

https://example.com/api/v1/client/subscribe?token=xxxx

token 是存取憑證,洩漏等於把套餐送人,排查時不要把完整連結貼到公開管道。

訂閱網域被阻斷

訂閱伺服器網域本身被阻斷時,直連更新必然失敗。兩條路:在用戶端設定裡開啟「透過代理更新訂閱」(各用戶端叫法略有差異);或者先用一個臨時節點連上代理,再更新訂閱。更新成功之後,訂閱裡的節點就可以正常使用了。

格式與解析問題

訂閱回傳的內容必須是 Clash 可識別的 YAML 設定,或可轉換的節點清單。機場如果只提供通用 v2ray 訂閱,需要換用其「Clash 訂閱」專用連結或訂閱轉換服務。自己手動改過訂閱檔案的還要注意 YAML 縮排——縮排錯了,報的就是解析失敗。

自動更新間隔

節點清單會隨機場端調整變化,長期不更新會出現「節點全在但全不可用」的假象。在用戶端設定裡開啟自動更新,間隔建議 24 小時上下,既不會太舊也不會頻繁打擾。具體設定路徑與更多失敗原因的逐項排查,見部落格專文《Clash 訂閱更新失敗的常見原因與自動更新設定方法》。

訂閱轉換服務的取捨

訂閱轉換能把 v2ray、SSR 等格式的節點清單轉成 Clash 設定,也能合併多個機場的訂閱。但轉換意味著把訂閱連結交給第三方:連結裡的 token 會被對方看到,轉換服務本身也可能記錄節點資訊。只在自己信任的轉換服務上使用,敏感套餐盡量用機場官方提供的 Clash 專用訂閱。轉換後設定裡的規則是轉換範本內建的,未必符合你的分流習慣,匯入後檢查一遍規則段再啟用。

多訂閱並存時的衝突

同時匯入多個訂閱時,用戶端一般按「設定」分別管理,切換設定才會切換節點群組。新手常見的困惑是「更新了訂閱節點卻沒變」——多半是更新的是 A 設定、目前啟用的是 B 設定。養成一個習慣:更新訂閱後確認目前啟用的設定名稱,再重新整理節點清單。

速度慢:能用但卡頓

慢是一種相對故障:鏈路是通的,但體驗差。先定位瓶頸段,再決定換節點、換協議還是改規則。

三段瓶頸定位

一條連線的速度取決於三段裡最窄的一段:本地到節點、節點自身頻寬、節點到目標站。判斷方法:同一節點下存取不同目標站——只有個別站慢,瓶頸在節點到該站的回程;所有站都慢,換節點對比,換節點後明顯改善是節點頻寬或本地到節點的鏈路問題,怎麼換都慢就查本地網路與用戶端本身。

延遲低不等於速度快

延遲決定「反應快不快」,頻寬決定「路寬不寬」。晚間高峰時低延遲節點照樣擁擠。判斷速度要看實際下載或影片載入表現,不要只盯著延遲數字選節點——延遲 50ms 的節點和 150ms 的節點,看影片可能沒有任何差別。

策略群組的選擇

url-test 策略群組自動選延遲最低的節點,但可能選中最擁擠的那個;負載均衡把連線分攤到多個節點,適合下載類場景;手動選擇最可控——在延遲相近的幾個節點裡輪換試用,找到目前時段最穩的。目標站被規則分流到繞遠路的節點群組也會變慢:打開連線面板,看這條連線實際命中了哪條規則、走了哪個節點,必要時調整規則順序或給該站指定固定節點。

協議與核心差異

基於 UDP 的新協議(Hysteria2、TUIC)在高丟包、高抖動的線路上明顯比傳統 TCP 協議抗卡;mihomo 核心對這兩類協議支援完整,桌面端首推的 Clash Plus 與 Clash Verge Rev、FlClash 均內建 mihomo。核心與協議差異的更多說明,見部落格《mihomo(Clash Meta)核心特性與原版 Clash 的區別》。

用戶端自身的效能開銷

規則數量巨大(幾萬條)的設定在低配裝置上會明顯拖慢連線建立速度:每條新連線都要順序比對規則,規則越多首包延遲越高。精簡規則集、把命中頻率高的規則前移,能直接改善「點開網頁要轉圈一秒」的體驗。TUN 模式比系統代理模式多一層虛擬網卡轉發,千兆寬頻下跑不滿速時,可以對比兩種模式的實際吞吐再決定常駐用哪個。日誌等級長期開在 debug 也會拖累效能,排查完記得調回 info 或 warning。

DNS 問題:解析異常與污染

典型症狀

能連代理,但部分網站打不開;打開的網站是「錯誤的地區版本」;廣告過濾規則時靈時不靈;nslookup 回傳明顯不合理的 IP。這些都指向 DNS 環節,而不是節點。

Clash 的 DNS 模組怎麼運作

用戶端內建 DNS 模組接管系統的網域解析,按設定的上游伺服器查詢,並配合規則決定「誰來解析、結果給誰」。兩種工作模式:redir-host 回傳真實解析的 IP;fake-ip 回傳 198.18.0.0/16 段的虛擬 IP,連線建立時核心再按網域轉發——解析快、天然抗污染,是多數用戶端的預設模式。

設定範例

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com

nameserver 負責直連網域的解析,fallback 負責走代理的網域;fake-ip-filter 列出必須回傳真實 IP 的網域(區域網路裝置、部分對 IP 敏感的應用程式)。改完 dns 段必須重新啟動核心或重新載入設定才生效,多數用戶端在設定裡有一鍵入口。

改完設定清快取

系統與瀏覽器都會快取 DNS,舊快取不清,新設定看起來就像沒生效:

DNS 洩漏自查

代理開啟後存取 DNS 洩漏測試網站:看到的解析伺服器應當是代理出口或設定的上游,而不是本地電信業者。出現本地電信業者 DNS 時,檢查系統 DNS 是否被寫死、瀏覽器是否開啟了「安全 DNS」繞過系統解析。

IPv6 引入的解析分叉

寬頻同時下發 IPv4 與 IPv6 時,系統可能優先走 IPv6 解析與連線,而節點只支援 IPv4 出站——表現是部分網站時通時斷、解析結果在兩種協議間漂移。兩種處理:在用戶端 DNS 設定裡過濾 AAAA 紀錄,強制只回傳 IPv4 結果;或者在系統網路設定裡暫時關閉 IPv6 驗證猜想。確認是 IPv6 引起後,再決定長期方案,不建議無腦全域關閉 IPv6。

區域網路與特殊網域的處理

路由器管理頁、NAS、印表機這類區域網路網域,必須回傳真實內網 IP 才能存取。fake-ip 模式下這些網域會被解析成虛擬段,直接打不開。把 *.lan、*.local 以及路由器的具體網域加進 fake-ip-filter,並確認規則裡區域網路段(192.168.0.0/16 等)走直連。公司內網網域同理,按實際後綴補充。

系統代理不生效:開關開了流量沒走代理

先驗證「生效」是什麼狀態

開啟系統代理後,瀏覽器存取 IP 查詢網站,出口應顯示節點所在地區;仍顯示本地電信業者,即未生效。驗證動作只要十秒,先做了再往下查。

Windows:檢查代理項目被改寫

設定 → 網路和網際網路 → 代理伺服器:「使用 Proxy 伺服器」應開啟,位址 127.0.0.1,埠與用戶端一致。安全軟體、其他代理工具會改寫這一項;用戶端寫入系統設定需要權限,必要時以系統管理員身份執行一次,讓用戶端拿到寫入權限。

macOS:授權與代理項目

系統設定 → 網路 → 目前網卡 → 詳細資訊 → 代理伺服器,確認網頁代理伺服器、安全網頁代理伺服器的勾選與埠。用戶端首次開啟系統代理時系統會彈出授權請求,點過「不允許」就再也寫不進去——在「隱私權與安全性」設定裡放行後重試。

瀏覽器層的干擾

SwitchyOmega 一類擴充功能會接管瀏覽器代理,與系統代理疊加衝突,二選一即可。瀏覽器的「安全 DNS」會讓網域解析繞過用戶端的 DNS 邏輯,表現為「IP 變了但內容不對」,排查時先關掉再驗證。

終端機與開發工具不走系統代理

終端機預設無視系統代理,需要明確設定環境變數:

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

git、npm、pip 另有各自的代理設定項,環境變數不一定全覆蓋。瀏覽器與終端機兩條線的逐項排查,見部落格專文《Clash 系統代理不生效的排查方法》。

終極方案:TUN 模式

TUN 模式用虛擬網卡接管整機流量,不依賴系統代理設定,對不遵守系統代理的應用程式(遊戲、部分命令列工具)同樣有效,也能繞開「代理項目被改寫」這類反覆發作的問題。原理與開啟步驟見部落格《Clash TUN 模式開啟教學》。

多代理工具共存的衝突

電腦上同時裝著多個代理類工具(加速器、封包擷取軟體、其他 VPN)時,系統代理設定會被反覆改寫,表現是「明明開了 Clash,代理項目卻指向別的埠」。只保留一個工具常駐,其餘徹底退出(不是關視窗,是退出程序);封包擷取工具用完隨手關代理,加速器不用時退出。企業 VPN 用戶端尤其強勢,連線公司 VPN 期間系統代理基本不可用,這種場景直接用 TUN 模式或接受「VPN 期間不走代理」的現實。

驗證清單:確認修復有效

修復後按三步確認:系統代理設定頁裡的位址與埠和用戶端一致;瀏覽器存取 IP 查詢網站顯示節點地區;curl 不帶 -x 參數直接請求也能走通(說明系統代理對命令列同樣生效,或至少瀏覽器鏈路完整)。三步都過,這一章才算真正閉環。

用戶端崩潰與無法啟動

先分清是誰崩了

介面閃退與核心啟動失敗是兩回事。核心失敗時用戶端一般會給出明確提示(核心啟動失敗、埠被佔用、設定解析錯誤),先看提示再動手;介面本身打不開,則優先重新安裝或換用戶端。

埠佔用

混合埠或外部控制埠被佔用——常見的佔用者正是上一次沒退乾淨的用戶端程序——核心會直接起不來。查佔用:

# Windows(系統管理員終端機)
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

結束佔用的程序,或在用戶端設定裡換一組埠。改完埠記得同步檢查系統代理設定裡的埠是否一致。

設定檔語法錯誤

YAML 對縮排極度敏感:必須用空格、不能用 Tab,層級錯一格就是解析失敗。手動改過 config.yaml 之後,用用戶端內建的設定檢查或 YAML 驗證工具過一遍。一個合法節點條目長這樣:

proxies:
  - name: "節點A"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

權限與系統元件

Windows 上 TUN 模式、服務模式需要安裝系統服務(用戶端內一般有一鍵安裝入口);macOS 首次開啟增強模式需要授權;安全軟體誤判會隔離核心檔案——加入白名單後重新安裝用戶端即可。

設定檔損壞與版本升級遺留

用戶端大版本升級後,舊設定目錄裡的快取、資料庫檔案可能與新版本不相容,表現為升級後打不開或一啟動就閃退。處理順序:先備份訂閱連結與自訂規則,再退出用戶端,把設定目錄整個重新命名(不要直接刪),重新啟動用戶端讓它產生全新目錄,最後重新匯入訂閱。絕大多數「升級後當了」都能用這套流程解決。設定目錄的位置各用戶端不同,一般在用戶端設定的「開啟設定目錄」入口可以直達。

日誌是當機排查的第一現場

用戶端起不來時,介面日誌可能看不到,但核心日誌檔案通常已經寫在磁碟上。到設定目錄或日誌目錄找最新的日誌檔案,從最後一行往前讀:panic、fatal、error 三類關鍵字附近就是當機原因。把這幾行原樣保存下來,無論是自己繼續查還是向別人求助,都比「它當了」三個字有用得多。

重置與重新安裝

設定目錄損壞的通用解法:備份訂閱連結 → 退出用戶端 → 重新命名設定目錄 → 重新啟動用戶端重新匯入。仍無法解決就換用戶端:Windows 與 macOS 首推 Clash Plus,備選 Clash Verge Rev、FlClash;Clash for Windows 與 ClashX Meta 已停止維護,新裝不建議繼續使用。全平台用戶端清單在下載頁。

行動裝置專項:Android 與 iOS

Android:背景被清除是第一死因

台灣常見的 Android 系統與品牌 ROM 的電池優化都會清理 VPN 常駐程序,表現是鎖螢幕一段時間後代理「自己關了」。處理路徑:系統設定 → 應用程式 → 找到用戶端 → 電池 / 耗電管理,設為「不最佳化」或「允許背景活動」;在最近任務畫面鎖定用戶端;允許自動啟動。Clash Meta for Android、FlClash、Surfboard 都在下載頁 Android 區,Clash Plus 為全平台首推。

Android:VPN 槽位互斥

系統同一時間只允許一個 VPN 運作。其他 VPN 或加速器佔著槽位時,用戶端啟動會失敗或直接頂掉對方。用用戶端的分應用程式代理功能縮小接管範圍,也能減少與其他工具的衝突面。

iOS:Clash Plus 與系統託管

iOS 端從 App Store 安裝 Clash Plus(官網 clashplus.io)。iOS 的 VPN 由系統託管,鎖螢幕後一般保持連線;低電量模式與關閉「背景 App 重新整理」會影響訂閱自動更新與保活表現,遇到「放著放著不更新」先查這兩項。

與桌面端設定互通

訂閱連結全平台通用:同一份機場訂閱可以同時匯入手機與電腦,規則與分流邏輯一致。本手冊前面各章關於 DNS、規則、協議的結論對行動裝置同樣成立,差別只在系統層的保活與權限。

行動網路特有的斷流場景

捷運、電梯、基地台切換時,行動網路會經歷短暫的完全斷線。VPN 隧道對斷線的容忍度因協議而異:TCP 類協議斷線後需要重新交握,恢復慢;Hysteria2、TUIC 這類基於 UDP 的協議有工作階段保持機制,網路恢復後幾乎無感續傳。經常在通勤路上使用的話,優先選 UDP 類協議的節點。Android 的「一律開啟 VPN」與「封鎖未走 VPN 的連線」兩個選項一起開,能在斷線期間避免流量裸奔,代價是斷線瞬間完全無網。

熱點分享與代理的疊加

手機開熱點給電腦用時,電腦端的流量預設不會經過手機上的代理——熱點轉發發生在系統底層,繞開了 VPN 應用程式。想讓電腦也走代理,要麼電腦上自己裝用戶端匯入同一訂閱,要麼在支援「熱點分享代理」的用戶端裡開啟對應功能(部分 Android 用戶端支援,需要 root 或特定系統版本)。iOS 個人熱點不支援疊加 VPN 代理,只能電腦端自行解決。

行動裝置症狀速查