#Clash 疑難手冊:按症狀分章的故障排查大全

開啟後無法上網:先分層,再動手

「開了 Clash 什麼都打不開」是最常見也最籠統的症狀。它可能出在四個完全不同的層級:本地網路本身斷了、客戶端沒有真正在監聽、系統沒有把流量交給客戶端、或者流量到了核心但規則把它導向了一個失效的出口。排查的第一原則是逐層縮小範圍,不要一上來就重裝客戶端或換訂閱。

第一步:確認本地直連正常

先把客戶端的系統代理或 TUN 模式關掉,直接存取一個台灣本地網站(例如電信業者官網)。如果關掉之後也打不開,問題在路由器、網路線或電信業者,與 Clash 無關,先解決基礎網路。如果直連正常、開代理後全斷,繼續往下。

第二步:確認連接埠在監聽

Clash 系客戶端預設在 7890 連接埠開啟混合代理(mixed-port,同時接受 HTTP 與 SOCKS)。用下面的指令確認連接埠確實被占用:

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

# macOS / Linux
lsof -i :7890

如果什麼都沒輸出,說明核心沒啟動成功——多半是設定檔解析失敗或連接埠被別的程式占用,直接跳到客戶端當機一章。如果連接埠在監聽,用 curl 走一遍代理測試連通性:

curl -x http://127.0.0.1:7890 -sS -o /dev/null -w "%{http_code}\n" \
  https://www.gstatic.com/generate_204

返回 204 說明「核心 + 目前節點」這條鏈路是通的,問題出在系統代理層,去看系統代理失效一章;返回逾時或錯誤,說明出口本身有問題,繼續看節點逾時。

第三步:排除規則誤傷

把客戶端切到全域(Global)模式再試一次。全域模式跳過所有分流規則,把流量統一交給你手選的節點:如果全域能通、規則模式不通,說明是規則把目標網域分給了失效的策略群組,或兜底的 MATCH 規則指向了 DIRECT。三種模式的分流邏輯差異可以讀這篇筆記:規則、全域、直連三種代理模式怎麼選。

第四步:看連線列表驗證流量走向

多數客戶端都帶一個「連線」或「Connections」面板,逐條列出目前活躍連線的目標網域、命中的規則與最終出口,這是判斷「流量到底有沒有走代理」最直接的證據。保持面板開著,再訪問一次打不開的網站,然後對照三種結果判斷:列表裡連一條相關記錄都沒有出現,說明流量根本沒進核心,問題在系統代理或 TUN 接管這一層;記錄出現了但「規則」一欄顯示 DIRECT,說明分流規則把它判成了直連,該補的是規則而不是換節點;記錄顯示的策略群組與出口節點都正確卻依然逾時,問題就落在節點出口這一段。先花十幾秒做完這一步,後面能省掉大量方向錯誤的嘗試。

如果客戶端介面沒有連線面板,也可以用外部控制連接埠查看即時連線。核心預設在 9090 連接埠提供 RESTful 介面,設定檔裡由 external-controller 指定,訪問 http://127.0.0.1:9090/connections 即可拿到與面板同源的原始資料;設定了 secret 時需要在請求標頭裡帶上對應的權杖。這個介面同樣能讀到目前生效的規則列表與策略群組狀態,適合在圖形介面卡死時做旁路診斷。

節點逾時:分清「一個逾時」和「全部逾時」

客戶端裡的延遲數字來自對一個測試位址的 HTTP 請求耗時,常用的是 https://www.gstatic.com/generate_204。顯示逾時意味著這次探測在限定時間內沒有拿到回應,原因可能在節點伺服器、傳輸協定、本地網路對特定連接埠的干擾,也可能只是測試位址本身抽風。排查前先回答一個問題:是個別節點逾時,還是所有節點一起逾時?

全部節點同時逾時

所有節點一起紅,基本可以排除節點本身的問題,優先懷疑三件事。其一,本地直連是否正常——回到上一章第一步。其二,系統時間是否準確:多數加密協定對時間偏差敏感,手動改過時區或虛擬機時鐘漂移都可能導致交握全軍覆沒,把系統時間設為自動同步再測。其三,訂閱是否整體過期或被伺服器端封鎖,登入訂閱提供方的使用者面板核對流量與到期時間,必要時按訂閱失敗一章重新拉取設定。

個別節點逾時

單個節點逾時最常見的原因就是那台伺服器負載高或線路波動,換一個同地區節點即可。如果某個節點長期時好時壞,可以用 url-test 類型的策略群組讓核心自動選擇目前可用的節點,寫法如下:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港-01
      - 日本-01
      - 新加坡-01

interval 是自動重測間隔(秒),tolerance 表示新舊節點延遲差超過這個毫秒數才切換,避免在兩個延遲接近的節點之間來回橫跳。策略群組的組織思路在教學頁與相關文章裡有更完整的說明。

延遲正常但實際用不了

讀懂延遲數字的含義

介面上的毫秒數是一次完整 HTTP 請求的往返耗時,包含握手、加密協商與代理伺服器轉發,因此天然比 ping 出來的網路延遲大一截,同一節點相差幾十毫秒完全正常,不必為此反覆重測。真正值得關注的是穩定性:連續測五次,數字在小範圍內浮動的節點,即便絕對值略高,實際體驗也比「一次 80 毫秒、一次 900 毫秒」的節點好得多。另外,批次測速時客戶端會同時向所有節點發起探測,短時間內的並發請求本身會互相擠佔頻寬,把結果整體拉高;想拿到準確數字,單獨測目標節點即可。測試位址被目標地區限制訪問時也會誤報逾時,可以把策略群組的 url 換成一個在該地區可正常訪問的 204 位址再看。

延遲測試只驗證「能建立連線」,不驗證頻寬,也不驗證 UDP。遊戲、語音通話依賴 UDP 轉發,如果協定或伺服器端沒開 UDP 支援,會出現「測速綠色、遊戲斷線」的錯位現象;這類問題優先聯繫訂閱提供方確認節點是否支援 UDP,客戶端側無法憑空修復。另外,延遲數字只反映「你到節點」這一段,節點到目標網站的那一段擁堵時,同樣會出現延遲很低但網頁打不開的情況,換一個出口地區通常立竿見影。

訂閱更新失敗:先看錯誤訊息,再決定走直連還是走代理

訂閱本質上是一個 HTTP(S) 位址,回傳一份 YAML 設定或可轉換的節點清單。更新失敗時客戶端一般會給出錯誤訊息,不同錯誤訊息對應完全不同的處理方式,不要盲目反覆點更新。

手動驗證訂閱位址

客戶端錯誤訊息有限時,直接用 curl 模擬一次拉取,把問題從客戶端剝離出來:

# 直連拉取
curl -sS -o sub.yaml -w "%{http_code}\n" "訂閱位址"

# 走本地代理拉取
curl -x http://127.0.0.1:7890 -sS -o sub.yaml -w "%{http_code}\n" "訂閱位址"

回傳 200 且 sub.yaml 裡能看到 proxies: 開頭的節點清單,說明訂閱本身健康,問題在客戶端設定(常見是 User-Agent 被伺服器端拒絕,換一個客戶端識別碼重試);兩條指令一條通一條不通,則說明訂閱網域在你的網路環境下被干擾,固定使用能通的那條路徑即可——多數客戶端在訂閱編輯介面都有「使用代理更新」開關。

更新成功但節點沒變化

部分客戶端對訂閱有本地快取,更新後記得看一眼設定的最後更新時間戳記。另外注意:手動改過設定檔裡的分流規則後再點訂閱更新,改動會被伺服器端下發的內容覆蓋——需要長期自訂規則時,應使用客戶端的「設定增強/合併腳本」類功能,而不是直接編輯訂閱落地的檔案。

速度慢:定位瓶頸在哪一段

「慢」是一條鏈路上任何一環的木桶效應:本地寬頻上限、你到節點的線路品質、節點伺服器頻寬、節點到目標站點的線路,以及加密協定本身的開銷。排查慢的問題,核心是先弄清慢在哪一段,而不是無腦換節點。

建立基準

先關掉代理測一次本地裸速,記下數字;再開代理、切到全域模式、選一個延遲最低的節點測一次。兩個數字的差距就是「代理鏈路開銷 + 節點瓶頸」的總和。如果裸速本身只有幾 Mbps,任何節點都救不了;如果裸速很高、代理後掉到十分之一以下,再繼續往下分。

常見原因與對策

讓不該走代理的流量直連

速度慢的隱形元兇經常是分流沒做好:系統更新、遊戲下載、雲端硬碟同步這類大流量本沒必要繞道出口。在規則模式下確認這些網域命中的是 DIRECT,必要時手動補規則。地理類規則(GEOIP、GEOSITE)能否正確命中,取決於本地資料庫是否新鮮,更新方法見這篇筆記:GeoIP 與 GeoSite 資料庫更新方法。

DNS 問題:污染、洩漏與 Fake-IP 的取捨

相當一部分「規則不生效」「個別網站打不開」「首次開啟很慢」的問題根子在 DNS。Clash 核心自帶 DNS 模組,理解它的兩種增強模式和 nameserver 的分層設計,能解決絕大多數疑難雜症。

症狀識別

典型的 DNS 污染表現是:網域能解析出 IP,但那個 IP 根本連不上,或解析結果明顯不屬於目標網站;而 DNS 設定不當的表現是網域規則(DOMAIN-SUFFIX 等)命中正常、GEOIP 規則錯亂,或者切換節點後仍存取到舊位址。用 nslookup 或 dig 對比本地解析與公開 DoH 的解析結果,可以快速確認是否被污染。

推薦的 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"
    - "time.windows.com"
    - "+.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query

enhanced-mode: fake-ip 讓核心用保留網段的虛假位址即時應答查詢,省掉真實解析的等待,並保證網域規則精確命中——這也是多數客戶端的預設模式。它的完整工作流程、與 redir-host 的差異,以及哪些場景必須排除,詳見這篇拆解:Fake-IP 模式原理詳解。

Fake-IP 的典型坑與排除清單

需要拿到真實 IP 的程式在 Fake-IP 下會出問題:區域網路裝置探索、NTP 時間同步、部分遊戲登入器、需要回連的 P2P 應用。症狀是這些程式拿到 198.18.x.x 的位址後行為異常。解決辦法不是關掉 Fake-IP,而是把相關網域加進 fake-ip-filter,讓它們走真實解析。改完設定後如果舊的虛假位址仍被系統快取,Windows 下執行 ipconfig /flushdns,macOS 下執行 sudo dscacheutil -flushcache 清一次快取。

系統代理失效:哪些流量根本不理會系統代理

系統代理的本質,是在作業系統層面登記一條「HTTP/SOCKS 代理在 127.0.0.1:7890」的建議——注意是建議,不是強制。瀏覽器和多數現代應用會遵守,但命令列工具、部分老軟體、以及 Windows 的 UWP 應用會無視它。理解這一點,一半的「失效」就有了答案:不是代理壞了,是那個程式壓根沒打算走代理。兩種流量接管方式的機制對比,推薦先讀:TUN 模式與系統代理有什麼區別。

Windows:UWP 迴環限制

微軟商店應用(UWP)預設被禁止存取本機迴環位址,也就是說即使系統代理指向 127.0.0.1,商店版應用的流量也發不進 Clash。多數 Windows 客戶端內建「UWP 迴環助手/Loopback 工具」,勾選目標應用放行即可;也可以用系統自帶指令手動放行,例如放行微軟商店:

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

# 查看目前已放行清單
CheckNetIsolation.exe LoopbackExempt -s

命令列與開發工具

終端機裡的 git、pip、npm、curl 不讀系統代理設定,需要明確宣告環境變數,或改用 TUN 模式整體接管:

# macOS / Linux(當前對話有效)
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

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

代理設定被搶或沒寫進去

開關「系統代理」後,去作業系統的代理設定頁親眼確認一次:Windows 在「設定 → 網路和網際網路 → 代理伺服器」,macOS 在「系統設定 → 網路 → 目前的網路服務 → 詳細資訊 → 代理伺服器」。如果位址不是 127.0.0.1:7890,常見原因有:其他代理軟體(或殘留的驅動程式)在反覆改寫設定、macOS 上目前活躍的網路服務不是被寫入的那一個(比如寫了 Wi-Fi 但實際走有線)。關閉衝突軟體、確認網路服務順序後重開開關即可。徹底繞開這一層麻煩的辦法是啟用 TUN 模式,用虛擬網路卡在網路層接管全部流量,代價是需要系統管理員權限並留意與其他虛擬網路卡類軟體的相容性。

客戶端當機與啟動失敗:從日誌找答案

客戶端「點了沒反應」「啟動就閃退」「執行中突然斷流」大多有明確的日誌線索,盲目重裝的命中率遠低於先讀一眼日誌。各客戶端都在設定或系統匣選單裡提供「開啟日誌/應用程式目錄」入口,排查前先把日誌等級調到 info 或 debug 重現一次。

啟動即退出:先查設定,再查連接埠

最常見的啟動失敗是設定檔解析出錯——YAML 對縮排和冒號後的空格極其敏感,手動編輯後少個空格整份設定就報廢。日誌裡會給出具體行號,按行號修復;改動較大時,可以先換回一份未修改的訂閱設定驗證客戶端本身是否正常,從而區分「設定問題」與「程式問題」。第二常見的是連接埠衝突:7890 或 9090(外部控制連接埠)被其他程式占用,日誌會出現 bind: address already in use 一類字樣,用上文的 netstat/lsof 找到占用者,或在設定裡改用其他連接埠。

執行中斷流或當機

TUN 模式下突然斷流,優先懷疑虛擬網路卡驅動與其他網路軟體(虛擬機、另一個代理工具、部分安全軟體)衝突,日誌中通常伴隨網路卡建立或路由寫入失敗的記錄;系統睡眠喚醒後網路不恢復,是各平台都存在的老問題,重開一次 TUN 或系統代理開關通常即可恢復。記憶體持續增長導致被系統砍掉的情況,多見於訂閱節點數量極大或規則集過多的設定,精簡訂閱、減少不必要的規則訂閱集能顯著緩解。

重置與更換客戶端

確認是程式自身問題時,卸載後手動清理殘留的應用程式資料目錄再重裝,比覆蓋安裝更徹底(記得先備份訂閱位址)。同一份訂閱在不同客戶端之間是通用的,某個客戶端在你的系統上水土不服時,直接換一個試試成本很低:各平台推薦順序與差異見客戶端對比,安裝包統一從取得客戶端頁面拿,首選各平台的 Clash Plus。

行動裝置專項:Android 與 iOS 各有各的坑

行動裝置的故障模式與桌面端不同:系統對背景程序和 VPN 通道的管理更激進,問題往往不在設定,而在系統策略。本章按平台分開說。

Android:VPN 權限與背景存活

Android 客戶端透過系統 VPN 介面接管流量,首次啟動必須同意「建立 VPN 連線」的系統彈窗;如果當時點了拒絕,之後會出現「點啟動沒反應」——去系統設定的 VPN 管理裡找到應用重新授權即可。第二大類問題是背景被砍:國產客製化系統的電池最佳化會掐掉長期駐留的 VPN 服務,表現為「用著用著斷了」「鎖屏一段時間後失效」。解決辦法是把客戶端加入電池最佳化白名單、允許自啟動與背景執行,並在最近任務裡鎖定。另外注意系統的「永遠開啟的 VPN」與「無 VPN 時封鎖連線」選項:前者能提升存活率,後者在客戶端異常退出時會直接斷網,排查斷網問題時記得看一眼這兩個開關的狀態。分應用代理(Access Control)設定錯誤也常被誤判為故障——如果只有個別 App 不走代理,先檢查它是否被排除在名單外。

iOS:按 App Store 渠道取得,注意設定體積

iOS 上透過網路擴充功能(Network Extension)實現接管,系統對這類擴充功能的背景記憶體限制很緊。訂閱裡節點數量過多、附帶大量規則集時,擴充功能行程可能因超限被系統終止,表現為「連線開關自動跳回關閉」。對策是精簡設定:讓訂閱方提供節點較少的精簡版訂閱,或在客戶端裡裁剪用不到的規則。iOS 客戶端從 App Store 取得,首選 Clash Plus(官網 clashplus.io),商店入口與說明見下載頁 iOS 區。切換 Wi-Fi 與行動網路後短暫斷流屬於擴充功能重建通道的正常現象,數秒不恢復時手動重開開關即可。

另一條思路:讓電腦替行動裝置代理

電視、遊戲機,或不方便裝客戶端的裝置,可以走「一台電腦跑 Clash、全屋共享」的方案:開啟 allow-lan 後,其他裝置把代理指向電腦的區域網路 IP 和混合連接埠即可。完整步驟(含 bind-address 取值與防火牆放行)見這篇筆記:Clash 區域網路共享代理設定。

還沒解決?下一步這樣走

按症狀章節走完仍未解決時,按這個順序繼續:第一,把日誌等級調到 debug,重現一次問題,日誌裡的錯誤原文往往比現象本身有資訊量得多;第二,做最小化驗證——換一份乾淨設定、換一個客戶端、換一個網路環境,三個變數各換一次,問題會被夾逼到具體環節;第三,去 常見問題 頁按分類翻一遍短問答,很多細碎問題(開機自啟、設定檔位置、模式切換失效)在那裡有直接答案。基礎操作不熟的話,回到 使用指南 把主線流程重走一遍,不少「疑難」其實是某一步被跳過了。