Clash 故障排除手冊

無法上網:開啟代理後全部斷網

定義:開啟代理後,任何網站都無法存取;關閉代理後網路立即恢復。這類故障說明流量確實進入了 Clash,但沒有被正確送出。排查按以下順序執行。

1.1 先區分「全斷」與「部分不通」

打開三類站點各測一次:一個中國大陸站點、一個海外站點、一個 IP 直連位址(如路由器管理頁 192.168.x.1)。三類全部不通才屬於本章範圍;只有海外站點不通,轉 DOC-02 檢查節點;只有部分站點不通或跳轉異常,轉 DOC-05 檢查 DNS 與規則。這一步花十秒,能避免後面走錯方向。

1.2 檢查代理模式與出站選擇

確認目前模式。規則模式(Rule)下,若設定檔缺少兜底規則 MATCH,未命中的流量可能被丟棄;全域模式(Global)下,若選中的出站是一個失效節點,則所有流量都會失敗;直連模式(Direct)下開啟系統代理,流量繞一圈本機再直連,一般不會斷網,但設定異常時可能出現迴環。處理辦法:先切到全域模式,手動選擇一個延遲正常的節點,確認能否恢復。能恢復,說明問題出在規則或策略組,回到規則模式逐段檢查;不能恢復,繼續向下。

1.3 檢查本機監聽埠

Clash 預設在本機 7890 埠(混合埠)監聽。若埠沒有起來,系統代理指向的就是一個空位址,表現為全部斷網。用指令確認監聽狀態:

# Windows(PowerShell 或 CMD)
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

無輸出,說明核心沒有成功監聽:檢查設定檔中 mixed-port 或 port 欄位,再看客戶端日誌裡是否有 bind 失敗的記錄(常見原因是埠被其他程式佔用,轉 DOC-07 的埠衝突小節)。有輸出但 PID 不是 Clash 程序,說明埠被佔,修改設定換一個埠,或結束佔用程序。

1.4 用 curl 繞過瀏覽器驗證鏈路

瀏覽器自身快取、外掛、DoH 設定都可能干擾判斷。用命令列直接走本機代理請求一個無內容探測位址:

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

回傳 HTTP/2 204 或 HTTP/1.1 204,說明「本機 → Clash → 節點 → 目標」整條鏈路是通的,問題在瀏覽器或系統代理層,轉 DOC-06;回傳超時或連接被重置,說明節點側不通,轉 DOC-02。

1.5 查看執行日誌

把日誌等級調到 info 或 debug,重現一次存取,觀察輸出。三類典型記錄:

• dial tcp ... i/o timeout:到節點伺服器的連接超時,節點不可達,轉 DOC-02。
• EOF 或 connection reset:連接建立後被中斷,多為節點側協定參數不匹配或鏈路被干擾,更換節點或聯繫訂閱提供方。
• no such rule / proxy not found:設定檔裡規則引用了不存在的策略組名稱,屬於設定錯誤,重新更新訂閱或修正手改的欄位。

節點超時:延遲測試全部或部分失敗

定義:在客戶端節點清單中執行延遲測試,結果顯示超時、-1 或空白。先明確一點:延遲測試測的是「經過該節點存取某個測試 URL 的完整耗時」,測試失敗不一定等於節點失效,也可能是測試位址本身不可達。

2.1 全部超時的四個常見原因

1. 訂閱已過期或流量用盡。登入訂閱提供方的使用者面板確認帳戶狀態。這是全部超時最高頻的原因,先查它,不要先懷疑軟體。
2. 本機網路本身不通。關閉代理,直接存取任意大陸站點確認基礎網路正常。基礎網路斷了,任何節點都會超時。
3. 測試 URL 被本機網路攔截。部分客戶端預設測試位址在某些網路環境下不可達,導致「節點其實可用但測試全紅」。把測試位址改為 https://www.gstatic.com/generate_204 或 http://cp.cloudflare.com/generate_204 後重測。
4. 系統時間偏差過大。部分加密協定對時間敏感,本機時間與標準時間相差超過一定範圍會導致交握失敗。開啟系統時間自動同步後重測。

2.2 部分超時:正常現象與處理邊界

訂閱裡通常包含數十個節點,個別節點在個別時段超時屬於常態,原因包括節點伺服器維護、線路波動、區域網路管制變化。處理原則:

• 同一地區多個節點全部超時,其他地區正常——該地區線路故障,換地區使用,等待提供方修復。
• 隨機零星超時——不需處理,策略組用 url-test 類型自動選擇可用節點即可。
• 長期固定某幾個節點超時——回饋給訂閱提供方,或在設定中將其排除。

2.3 讓策略組自動避開失效節點

手動選擇節點的策略組在節點失效時不會自動切換。將常用策略組改為自動測速類型,可以顯著減少「突然斷了」的感知。範例:

proxy-groups:
  - name: "自動選擇"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 60
    proxies:
      - "節點A"
      - "節點B"
      - "節點C"

欄位說明:interval 為重測間隔秒數,不建議低於 120,過於頻繁的測速會產生額外請求;tolerance 為容差毫秒數,新節點延遲需比目前節點低出該值才切換,避免在兩個延遲接近的節點間反覆橫跳。

2.4 延遲數值的正確讀法

延遲測試走完整 HTTP 請求,數值受節點物理距離、協定開銷、測試位址位置三重影響。經驗參考:亞洲近距離節點幾十到一百多毫秒,歐美節點兩百到四百毫秒屬正常區間。延遲低只代表交握快,不代表頻寬大;下載速度問題轉 DOC-04 處理。

訂閱失敗:匯入報錯與更新失敗

定義:貼上訂閱連結後匯入報錯,或已有訂閱點擊更新時失敗。訂閱本質是一個透過 HTTP 拉取的遠端設定檔,排查思路與排查「一個網址打不開」相同:先確認連結本身,再確認網路路徑,最後確認內容格式。

3.1 確認連結本身有效

1. 核對連結完整性。訂閱連結通常很長且含 token 參數,從聊天工具複製時容易被截斷或混入換行、空格。建議從提供方使用者面板重新複製,不要轉手多次。
2. 確認連結類型。Clash 系客戶端需要 Clash 格式(YAML)的訂閱;部分提供方對不同客戶端給不同連結,拿錯格式會報「解析失敗」。多數機場支援在連結後附加參數指定格式,具體以提供方說明為準。
3. 在瀏覽器中直接開啟連結。能看到一段 YAML 文字(以 proxies:、port: 等欄位開頭),說明連結與內容都正常,問題在客戶端側;回傳 404 或錯誤頁,說明連結失效,找提供方重簽。

3.2 拉取階段失敗的處理

連結有效但客戶端更新報超時:訂閱伺服器本身可能在受干擾的網路路徑上。兩個處理方向:

• 用已有可用節點中轉拉取。Clash Verge Rev 等客戶端在訂閱設定裡提供「使用代理更新」開關;前提是目前至少有一個能用的舊設定。
• 命令列重現問題。用 curl 模擬客戶端請求,觀察具體失敗在哪一步:

# 直連拉取(把連結換成自己的,範例 token 為佔位假值)
curl -I "https://example.com/api/v1/client/subscribe?token=xxxx"

# 經本機代理拉取
curl -x http://127.0.0.1:7890 -I "https://example.com/api/v1/client/subscribe?token=xxxx"

直連失敗、走代理成功,說明訂閱伺服器直連不可達,開啟「使用代理更新」即可;兩者都失敗,說明伺服器側異常,等待或聯繫提供方。

3.3 User-Agent 限制

部分訂閱伺服器按請求的 User-Agent 回傳不同格式,或拒絕陌生 UA。瀏覽器能開啟、客戶端卻解析失敗時,可在客戶端訂閱設定中把 UA 手動改為 clash 或 clash.meta 後重試。這一項在更換客戶端後訂閱突然失效的場景中尤其常見。

3.4 更新失敗但舊設定仍可用

客戶端會快取上一次成功拉取的設定,訂閱更新失敗不影響繼續使用舊節點。因此更新失敗不必立即處理連接問題,但要注意:舊設定中的節點位址可能隨提供方輪換而逐漸失效,表現為可用節點越來越少。盡快按本章 3.1–3.3 恢復更新能力。

速度慢:連接正常但頻寬不達預期

定義:網頁能開、影片能放,但速度明顯低於本地寬頻水準或以往體驗。速度問題的變數最多,必須逐層隔離:本機網路 → 節點 → 協定 → 規則 → 目標站點。

4.1 建立基準:先測直連,再測代理

關閉代理,對大陸測速伺服器跑一次測速,記錄數值作為本地寬頻基準;開啟代理,選定一個節點,對同一目標或節點所在地區的測速點再跑一次。代理速度達到基準的一半以上,通常屬於正常損耗區間;差距懸殊時繼續向下排查。

4.2 節點側因素

• 節點負載。熱門時段(夜間)公共節點使用者集中,頻寬被攤薄。換冷門地區節點或錯峰對比,差異明顯即可確認。
• 線路類型。同一訂閱內不同節點走的國際線路品質差異很大。逐個實測常用的三五個節點,記錄各自的穩定速度,固定使用表現好的,不要只看延遲數字選節點。
• 倍率標記。部分提供方對高品質線路設定流量倍率,節點名稱中常有標註,選擇時留意。

4.3 客戶端與協定側因素

• 核心版本。mihomo 核心對新協定與並行效能的最佳化持續更新,長期未升級客戶端可能損失效能。到 安裝檔頁 取得目前版本;Clash Plus 與 Clash Verge Rev 均內建 mihomo 核心。
• UDP 支援。視訊通話、遊戲、部分串流媒體依賴 UDP。節點或設定未放行 UDP 時,這類應用會退化或卡頓。確認設定中相關代理的 udp: true 欄位,以及提供方是否支援 UDP 轉發。
• 瀏覽器 QUIC。瀏覽器對部分站點走 HTTP/3(UDP 443),在 UDP 轉發品質差的節點上反而更慢。規則中封禁 QUIC 強制回落 TCP 是常用手段:

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),REJECT

4.4 規則側因素:確認流量走向正確

速度慢的一個隱蔽原因是「本該直連的流量走了代理」。大陸站點繞道海外節點再回來,速度必然大幅下降。在客戶端的連接面板查看目前活動連接,確認大陸網域命中 DIRECT、海外網域命中代理策略組。分流規則設定不當的,參閱站內文章 規則分流實戰 校正。

4.5 本機環境因素

Wi-Fi 訊號弱、路由器效能瓶頸、其他裝置佔用頻寬,都會被誤判為「節點慢」。用網路線直連或靠近路由器複測一次,排除本機干擾。軟路由/路由器上跑核心的使用者,還需關注裝置 CPU 佔用——加密流量的吞吐受限於裝置算力,低階裝置百兆封頂屬正常現象。

DNS 異常:解析錯誤、洩漏與部分站點打不開

定義:整體網路可用,但部分站點打不開、跳到錯誤頁面,或偵測工具顯示 DNS 洩漏。DNS 是 Clash 故障中最不直觀的一類,因為症狀表現在「某些網站」,根源卻在解析層。

5.1 判斷是否屬於 DNS 問題

對打不開的站點執行:換用 IP 直連能通(如果該站支援)、或在客戶端日誌中看到該網域解析出的 IP 明顯異常(如解析到保留位址、明顯不屬於目標服務商的位址段),即可判定為解析問題。另一個典型信號:開啟代理後某網站提示「您所在地區不可用」,但節點地區明明正確——多為 DNS 請求走了直連,暴露了真實位置。

5.2 理解 fake-ip 與 redir-host

Clash 的 enhanced-mode 有兩種取值。fake-ip 模式下,核心對網域請求即時回傳一個 198.18.0.0/16 段的虛假位址,真實解析推遲到出站時進行,優點是回應快、天然防污染,缺點是個別依賴真實 IP 的程式(區域網路探索、部分遊戲平台)會異常;redir-host 模式回傳真實解析結果,相容性好但更依賴上游 DNS 的品質。一般桌面與行動端建議 fake-ip,配合過濾名單排除區域網路網域。

5.3 可直接套用的 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://120.53.53.53/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

結構說明:nameserver 負責日常解析,填大陸 DoH 保證大陸網域解析快且準;fallback 負責疑似被污染網域的二次解析,填海外 DoH;fallback-filter 以 GeoIP 判定——解析結果不屬於 CN 位址段時,採用 fallback 的結果。各欄位的完整原理與劫持場景,參閱站內文章 Clash DNS 設定詳解。

5.4 DNS 洩漏的確認與處理

1. 經代理存取 DNS 洩漏偵測站點,查看列出的解析伺服器歸屬。全部為節點所在地區的伺服器為正常;出現本地電信商伺服器即為洩漏。
2. 確認洩漏來源。常見來源三個:瀏覽器內建 DoH(設定裡獨立設定了 DNS over HTTPS,繞過了 Clash)、系統代理模式下 UDP 53 請求不經代理、IPv6 解析旁路。
3. 逐項處理:關閉瀏覽器內建安全 DNS;開啟 TUN 模式讓 DNS 請求也被接管(見 DOC-06);設定中設定 ipv6: false 或補全 IPv6 規則。

5.5 GeoIP 資料庫過舊導致的誤判

規則中的 GEOIP,CN,DIRECT 依賴本機 GeoIP 資料庫。資料庫長期未更新時,新啟用的位址段會被誤判,表現為個別大陸站點錯誤走代理、或個別海外站點錯誤直連。多數客戶端在設定中提供 GeoIP/GeoSite 資料庫更新入口,執行一次更新並重啟核心即可。更新失敗時,先確認目前代理可用,再用「經代理更新」的方式重試。

系統代理不生效:客戶端在跑,流量卻直連

定義:客戶端顯示運行正常、節點延遲正常,但瀏覽器或應用程式的流量並未經過代理。核心認知:「系統代理」只是作業系統層的一個建議性設定,應用程式可以遵守,也可以無視。這決定了本章的排查框架。

6.1 確認系統代理設定已寫入

先確認客戶端的「系統代理」開關處於開啟狀態,再到作業系統層核對:Windows 在「設定 → 網路和網際網路 → 代理」查看手動代理是否指向 127.0.0.1:7890;macOS 在「系統設定 → 網路 → 詳細資訊 → 代理」查看 HTTP/HTTPS 代理項。客戶端開了但系統裡沒寫入,常見原因是權限不足或被其他代理軟體搶佔了設定,重啟客戶端或退出衝突軟體後重試。

6.2 哪些流量天然不走系統代理

6.3 命令列工具的代理設定

# macOS / Linux(目前終端機會話生效)
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:7890

# Windows PowerShell
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:HTTP_PROXY="http://127.0.0.1:7890"

# git 單獨設定(全域)
git config --global http.proxy http://127.0.0.1:7890

驗證方式:執行 curl -I https://www.gstatic.com/generate_204,在客戶端連接面板看到來自 curl 的連接記錄即為生效。

6.4 用 TUN 模式取代系統代理

TUN 模式建立一塊虛擬網路卡,在系統路由層接管全部流量,不依賴任何應用程式的配合,是解決「不遵守系統代理」問題的根本方案。開啟要點:桌面端需授予管理員/系統擴充功能權限;首次開啟需安裝服務元件(客戶端會引導);開啟後建議關閉系統代理開關,避免雙重代理。原理與分平台步驟,參閱站內文章 TUN 模式原理與開啟步驟。

6.5 瀏覽器外掛與 PAC 的衝突

瀏覽器安裝過 SwitchyOmega 等代理外掛時,外掛設定的優先權高於系統代理。表現為系統代理明明正確,瀏覽器仍按外掛舊規則走。處理:將外掛切到「系統代理」情境模式,或直接停用外掛。同理,系統裡殘留的 PAC 自動設定腳本位址也會覆蓋手動設定,排查時把「自動偵測設定」與「使用設定腳本」一併關閉。

客戶端崩潰:啟動失敗、閃退與介面卡死

定義:客戶端無法啟動、啟動後立即退出、核心反覆重啟,或介面長時間無回應。這類問題九成落在四個原因上:設定語法錯誤、埠衝突、權限不足、安裝檔損毀。按命中率從高到低排查。

7.1 設定檔語法錯誤

YAML 對縮排與冒號後的空格極其敏感,手動編輯設定後核心起不來是最常見的崩潰原因。定位方法:查看客戶端日誌(Clash Verge Rev 的應用程式日誌、各客戶端設定中的日誌入口),核心會在報錯中給出行號,例如 yaml: line 42: mapping values are not allowed in this context。處理:按行號修正縮排,或暫時切回未改動過的訂閱設定驗證是否恢復。改動設定前先複製備份,是成本最低的保險。

7.2 埠衝突

7890(代理)、9090(外部控制)等埠被其他程式佔用時,核心啟動即失敗。典型衝突方:另一個未完全退出的 Clash 執行個體、其他代理軟體、開發除錯服務。定位與處理:

# Windows:找到佔用 7890 的程序 PID,再按 PID 查程序名
netstat -ano | findstr 7890
tasklist | findstr 

# macOS / Linux
lsof -i :7890

確認佔用方後,結束該程序,或在設定中改用其他埠(同時更新系統代理指向)。多個 Clash 系客戶端不要同時執行,卸載棄用的那個。

7.3 權限與安全軟體

• Windows:防毒軟體可能攔截核心程序或刪除核心檔案,表現為「昨天還能用,今天啟動就退」。將客戶端安裝目錄加入白名單後重裝。誤報成因與處理細節,參閱 Windows 安裝全流程與常見坑。
• macOS:首次啟動被攔時,到「系統設定 → 隱私權與安全性」允許執行;TUN 模式的系統擴充功能需單獨核准。
• TUN 相關崩潰:開啟 TUN 需要管理員權限,服務元件安裝不完整會導致開啟即崩。以管理員身份重裝服務元件,或先關閉 TUN 用系統代理模式驗證客戶端本體正常。

7.4 安裝損毀與殘留衝突

升級失敗、磁碟異常都可能損毀程式檔案。處理順序:先卸載,手動清理殘留目錄(注意:設定與訂閱一般存放在使用者資料目錄,與程式目錄分離,清理程式目錄不會丟設定;若要徹底重置,再刪使用者資料目錄),然後從 安裝檔頁 重新下載安裝。反覆崩潰且無明確日誌線索時,換用同核心的另一客戶端交叉驗證——例如 Clash Verge Rev 崩潰而 Clash Plus 正常,可判定問題在客戶端本體而非設定與網路。

行動端專項:Android 與 iOS 的平台特有問題

行動端客戶端(Android 端的 Clash Plus、Clash Meta for Android、FlClash;iOS 端的 Clash Plus)統一透過系統 VPN 介面接管流量,故障模式與桌面端有明顯差異,單列一章。

8.1 Android:VPN 無法建立

1. 確認系統 VPN 授權。首次啟動會彈出「連接請求」授權框,誤點拒絕後需到系統設定的 VPN 管理頁刪除該應用程式的 VPN 設定,重新啟動客戶端觸發授權。
2. 檢查 VPN 互斥。Android 同一時刻只允許一個應用程式持有 VPN 通道,其他 VPN 類應用程式(含部分安全軟體的「網路保護」功能)在執行時,Clash 無法建立連接。停用衝突應用程式後重試。
3. 部分客製化系統(工作資料、兒童模式)限制 VPN 權限,需在對應管理入口放行。

8.2 Android:背景被關閉與斷流

國產客製化系統的激進省電策略是行動端斷流的首要原因,表現為鎖螢幕一段時間後網路中斷、通知列圖示消失。處理清單:

• 在系統電池設定中將客戶端設為「無限制」/「不最佳化」。
• 在多工介面為客戶端加鎖(下拉鎖定卡片),阻止一鍵清理誤關。
• 開啟客戶端的前台服務常駐通知,不要為了清爽關掉它——常駐通知是系統判定程序重要性的依據之一。
• 部分系統需額外允許「自啟動」與「背景彈出介面」權限。

8.3 Android:分應用程式代理

客戶端設定中的「分應用程式代理」(Per-App Proxy)可指定哪些應用程式走 VPN。兩種模式:白名單(僅清單內應用程式走代理)與黑名單(清單內應用程式繞過)。銀行類應用程式對 VPN 敏感時,加入繞過清單可解決其風控報錯;反過來,發現某應用程式始終直連,先檢查它是否被列入了繞過名單。修改分應用程式設定後需重啟 VPN 生效。

8.4 iOS:Clash Plus 使用要點

iOS 端透過 App Store 安裝 Clash Plus,基於系統 Network Extension 框架執行。平台特有注意點:

• 首次啟動需在系統彈窗中允許新增 VPN 設定,拒絕後到「設定 → 一般 → VPN 與裝置管理」處理。
• 系統對 Network Extension 的記憶體限額遠低於一般應用程式,規則集過大或節點過多的設定可能觸發擴充功能程序被系統回收,表現為 VPN 圖示閃斷。精簡訂閱規模、避免載入超大規則集可緩解。
• iOS 的 VPN 同樣全域互斥,切換代理應用程式前先斷開另一個的連接。
• 切換 Wi-Fi 與行動網路時出現短暫斷流屬系統網路堆疊切換的正常現象,數秒內自動恢復;長時間不恢復時,手動關開一次連接。

8.5 行動端訂閱更新失敗

手機端更新訂閱報錯的排查與 DOC-03 相同,補充兩點行動端特有因素:行動網路下部分電信商對陌生網域的解析與連接策略更嚴格,切到 Wi-Fi 重試可區分;省電模式會限制背景網路請求,前台手動更新不受影響,但「自動更新訂閱」任務可能長期未執行,導致節點悄然過期——發現節點批量失效時,先手動更新一次訂閱再測。

END OF FILE / C-007

按上述八章仍未解決的問題,建議攜帶三項資訊求助:客戶端名稱與平台、重現步驟、關鍵日誌片段(隱去訂閱連結與 token)。零散高頻問答見 疑難解答;從零設定回到 設定教學;更換或升級客戶端到 安裝檔頁,全平台首推 Clash Plus。