Clash 故障排除大全

本頁與使用指南分工明確:指南涵蓋從安裝到首次成功連線的主線操作,適合第一次設定的用戶跟著走;本頁面向「已經裝好、但某個環節出了問題」的情境,依症狀定位章節,自上而下執行排查步驟即可。各章的步驟依命中機率排序,前幾步就能解決大多數情況。還沒安裝用戶端的先到下載頁取得安裝檔(全平台首推 Clash Plus),再依指南完成初始設定,遇到問題再回到本頁查閱。

一、排查總則與日誌讀法

動手改任何設定之前,先建立兩個習慣:分層定位,以及一次只改一個變數。代理鏈路從上到下可以拆成五層——用戶端介面、核心行程、設定與訂閱、遠端節點、本機系統環境。症狀出在哪一層,決定了該往哪個方向查。亂序嘗試「重裝、換訂閱、改 DNS」三招齊發,經常把原本單一的問題改成疊加故障。

分層定位的基本順序

• 用戶端層:介面是否正常開啟、開關狀態是否與預期一致、有沒有錯誤彈出視窗。
• 核心層:核心行程是否在運行、監聽的連接埠是否可連線(見第二章的 curl 驗證法)。
• 設定層:訂閱是否載入成功、規則模式(Rule/Global/Direct)選的是哪一個、規則是否命中預期的出口。
• 節點層:節點是否可用、延遲測試結果如何、訂閱是否過期。
• 系統層:系統代理/TUN 是否真正寫入系統、防火牆與其他網路軟體是否干擾。

日誌頁與日誌等級

日誌頁是排查的主要資訊來源。多數用戶端預設等級是 info,能看到每條連線的目標網域、命中的規則與最終出口,足以回答「這條流量到底走了哪個節點」。定位 DNS 或握手層面的問題時暫時切到 debug,排查完再改回來,否則日誌量會明顯拖慢介面。

最小重現設定

當懷疑「問題出在訂閱裡的複雜設定」時,用一份最小設定驗證核心與節點本身是否正常。把下方範例存成 minimal.yaml,替換成任意一個可用節點的參數,在用戶端裡作為本地設定載入。最小設定能通、完整訂閱不通,問題就鎖定在訂閱的規則或 DNS 段;最小設定也不通,問題在節點或系統層。

mixed-port: 7890
log-level: info
mode: rule
proxies:
  - name: test-node
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
proxy-groups:
  - name: PROXY
    type: select
    proxies: [test-node]
rules:
  - MATCH,PROXY

二、開啟代理後無法上網

症狀定義:開啟用戶端後所有網頁打不開,或關閉用戶端後網路也回不來。這是最常見也最容易誤判的一類問題,關鍵是先把「代理鏈路壞了」和「系統代理設定殘留」區分開來。

第一步:確認本機基礎網路

退出用戶端,直接存取一個台灣本地網站。打不開表示本機網路本身有問題,與代理無關,先處理路由器或電信業者端。打得開再繼續下一步。如果退出用戶端後仍然全網打不開,大概率是系統代理殘留,直接跳到本章「系統代理殘留清理」小節。

第二步:用指令繞過瀏覽器驗證代理連接埠

瀏覽器有自己的代理快取與擴充功能干擾,不適合當測試工具。用 curl 直接對核心連接埠發送請求,結果乾淨可信:

# 驗證核心代理連接埠是否可用
curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

# 回傳 HTTP 204 → 核心與節點鏈路正常,問題在系統代理層,看第七章
# connection refused → 核心沒有在監聽,看第八章(行程/連接埠問題)
# 長時間無回應逾時 → 節點不可用,看第三章

第三步:檢查規則模式與出口

代理頁頂部的模式開關誤切也會造成「全網打不開」:Global 模式指向了一個已失效的節點,所有流量都會跟著失效;Direct 模式在某些網路環境下則表現為部分網站無法連線。日常保持 Rule 模式,並確認策略群組目前選中的節點延遲測試為綠色。另外檢查訂閱裡是否有 MATCH,REJECT 之類的保底攔截規則被意外啟用——日誌頁裡如果大量連線顯示命中 REJECT,就是這類規則在攔。

系統代理殘留清理

用戶端異常退出(崩潰、強制關閉行程)時來不及還原系統代理設定,系統仍然把流量指向已經不存在的 127.0.0.1:7890,表現為「關了用戶端反而全網斷線」。處理辦法:重新開啟用戶端再正常退出一次,通常會自動還原;不行就手動清除:Windows 在「設定 → 網路和網際網路 → Proxy」裡關閉「使用 Proxy 伺服器」;macOS 用指令:

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off

三、節點全部超時或延遲測試失敗

先區分「全部超時」和「部分超時」,兩者的原因幾乎不重疊。

全部節點超時

1. 檢查本機時間。多數加密協定對時間偏差敏感,系統時間與標準時間差超過一兩分鐘,握手會全部失敗。開啟系統的自動時間同步,手動改過時區的要重點檢查。
2. 檢查訂閱是否過期。服務商在訂閱到期後通常保留節點條目但拒絕連線,表現就是全部超時。登入服務商後台確認有效期限,過期續費後更新訂閱。
3. 檢查防火牆與安全軟體。Windows 首次執行核心時如果拒絕了防火牆授權彈出視窗,對外連線可能被靜默攔截。在「Windows 安全中心 → 防火牆與網路保護 → 允許應用程式透過防火牆通訊」裡確認核心行程被放行,第三方安全軟體同理。
4. 換一個網路環境交叉驗證。用手機開熱點讓電腦連上再測一輪。熱點下正常、原網路下全超時,說明目前網路對代理協定有干擾,與用戶端和訂閱無關。

部分節點超時

個別節點超時屬於正常現象:節點伺服器故障、線路波動、被目標網路封鎖都會造成。處理原則很簡單——切到延遲正常的節點用,過幾小時或訂閱更新後再看。如果某個地區的節點長期全滅,向服務商反映,用戶端這邊沒有可修的東西。

正確理解延遲數字

延遲測試是向 url-test 指定的測試位址發送一次請求並計時,數字反映的是「到測試目標的一次往返」,不等於實際瀏覽體驗;測試位址本身無法連線時,健康的節點也會顯示超時。測試位址可以在策略群組裡自訂:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: [node-a, node-b]

延遲數字與真實體驗的落差來源(測試目標、封包遺失、頻寬瓶頸),部落格裡有一篇專門拆解:Clash 延遲測試原理拆解。

四、訂閱匯入與更新失敗

訂閱問題的錯誤訊息量很大,先照著錯误关键字对表,再看細分小節。

格式不符

「連結在其他軟體裡能用、在 Clash 裡匯入失敗或節點為空」,九成是格式問題:Clash 系用戶端吃的是完整 YAML 設定,而有些連結回傳的是 Base64 編碼的裸節點清單。判別方法是把連結貼到瀏覽器裡開啟——看到 proxies:、rules: 這類欄位是 YAML,看到一大段沒有空格的字母數字是 Base64。服務商後台通常提供「Clash 訂閱」專用連結,優先使用它;沒有的話經訂閱轉換工具轉成 Clash 格式再匯入。各格式的結構差異與轉換注意事項見部落格:Clash 訂閱格式科普。

更新訂閱的網路環回問題

訂閱伺服器在某些網路環境下無法直連,更新請求本身就需要走代理;但代理又依賴訂閱裡的節點——雞生蛋的問題。多數用戶端在訂閱設定裡提供「透過代理更新」開關:節點還能用時開著它更新;節點全掛時關掉它、換到可以直連訂閱伺服器的網路(比如手機行動數據熱點)更新一次,恢復節點後再切回來。

手動匯入保底方案

任何自動更新都失敗時,還有一條穩定退路:用瀏覽器直接開啟訂閱連結,把回傳內容另存為 .yaml 檔案,在用戶端設定頁選擇「匯入本地檔案」。這條路徑不經過用戶端的下載邏輯,能繞開 UA、代理環回等所有網路端干擾,也常用於驗證「到底是連結壞了還是用戶端下載環節壞了」。

五、連線正常但速度慢

先分清延遲與頻寬

「慢」有兩種:開啟網頁前的等待久,是延遲高;影片畫質上不去、下載速率低,是頻寬不足。延遲低不代表頻寬大——延遲測試只發送一個很小的請求,測不出吞吐量。兩者的排查方向不同:延遲高優先換物理距離更近的節點;頻寬低優先排查節點倍率與本地鏈路。

排查順序

1. 換節點對比。同一訂閱裡換三個以上不同地區的節點各測一次。全都慢,繼續往下;個別慢,是節點本身壅塞,避開即可。
2. 測直連頻寬做基準。關閉代理,對台灣本地測速站跑一次頻寬測試。直連本身只有幾十 M,代理速度不可能超過它,預期要先校準。
3. 排查本機佔用。下載工具、雲端同步、系統更新都會擠占上傳與下載。日誌頁或連線頁依流量排序,揪出吃頻寬的行程。
4. 核對分流是否錯位。規則設定不當會讓台灣本地流量繞道海外節點,表現為「台灣本地網站也變慢了」。在日誌頁確認台灣本地網域命中的是 DIRECT;不是的話檢查規則集順序,通常是自訂規則把 GEOIP 保底規則擋在了後面。
5. 晚間高峰交叉驗證。只在每天固定時段慢,是線路壅塞的典型特徵,換非熱門地區節點或與服務商確認線路類型。

六、DNS 相關問題

兩種解析模式的差異

Clash 系核心處理 DNS 有 fake-ip 與 redir-host 兩種增強模式。fake-ip 用 198.18.0.0/16 保留網段的假位址回應本機查詢,真實解析發生在節點端,匹配快、洩漏少,是目前的主流預設;redir-host 則在本地完成真實解析。原理層面的完整拆解見部落格:Fake-IP 模式原理詳解。一份運作正常的 DNS 段大致長這樣:

dns:
  enable: true
  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

典型症狀與處理

• 用 IP 能存取、用網域名稱打不開:DNS 解析環節故障。檢查設定裡 dns.enable 是否為 true、nameserver 是否可連線;暫時把日誌切到 debug,能直接看到每條查詢送給了誰、答了什麼。
• 某軟體顯示連到 198.18.x.x:這是 fake-ip 的假位址,被不走代理的程式拿到了。把該程式涉及的網域加進 fake-ip-filter,讓這些查詢回傳真實位址。
• 區域網路裝置連不上(印表機、NAS、投放螢幕):fake-ip 接管了本地網域解析。確認 fake-ip-filter 裡有 *.lan、+.local 這類本地後綴;有問題的裝置用固定主機名稱的,把主機名稱一併加入。
• 切換網路後全網解析異常:fake-ip 快取與新網路環境不一致。用戶端裡執行「清除 fake-ip 快取」(多數用戶端在設定或首頁提供按鈕),或重啟核心。
• 遊戲連線、P2P 類應用異常:這類應用對真實 IP 敏感,fake-ip 下容易出問題。要麼給相關網域加 filter 例外,要麼整體換到 redir-host 模式測試。

七、系統代理未生效

系統代理的能力邊界

「系統代理」只是向作業系統登記一個 HTTP 代理位址,只有主動讀取這項系統設定的程式才會走代理——瀏覽器和多數常見桌面軟體會讀,但命令列工具、部分聊天與遊戲用戶端、不少背景服務從來不讀。這不是故障,是機制邊界。判斷方法:瀏覽器走代理正常、某個特定軟體不走,基本可以斷定是該軟體不讀系統設定。

讓命令列走代理

終端機裡的 git、pip、npm 等工具靠環境變數識別代理,目前工作階段暫時設定:

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" 等效設定。需要長期生效再寫進 shell 設定檔,排查階段建議只做暫時設定,避免忘記清理造成新問題。

頑固程式交給 TUN 模式

TUN 模式建立一塊虛擬網卡,在網路層接管全部 TCP/UDP 流量,不依賴程式自覺,是解決「某軟體死活不走代理」的通用方案。兩種方式的對照:

系統代理開關開了卻沒寫進系統

少數情況下用戶端顯示已開啟、系統設定裡卻是空的:多為權限不足或被其他軟體反向覆寫。以管理員身分執行用戶端重試;仍不行就檢查是否有安全類、網路加速類軟體在開機後重寫代理設定,與它們的衝突只能二選一。

八、用戶端崩潰與異常退出

啟動即退:先查設定解析

點開就閃退、或系統匣圖示一閃而沒,首先懷疑設定檔解析失敗。YAML 對縮排與冒號後的空格極其敏感,手動編輯過設定的要重點回查。定位方法:找到用戶端日誌檔案(通常在用戶端資料目錄的 logs 子目錄),看最後幾行的 error 記錄,解析錯誤會給出行號;或者把訂閱切換回未改動的版本、用第一章的最小設定啟動,能起來就證明是設定問題。

連接埠被佔用

核心啟動時監聽的連接埠被其他行程佔著(常見於上一個核心行程沒退乾淨、或另一個代理軟體在跑),會啟動失敗或反覆重啟。查佔用:

# Windows
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

查到佔用行程後結束它,或在用戶端設定裡把 mixed-port 改成一個空閒連接埠(比如 7891)再啟動。改了連接埠的話,第七章裡所有寫死 7890 的地方同步替換。

快取損壞與乾淨重裝

運行中隨機崩潰、介面白屏、設定改不動,可嘗試清理用戶端快取:退出用戶端,進資料目錄刪除快取類子目錄(名稱通常含 cache),保留 profiles(訂閱與設定)不動,再啟動。仍不穩定就乾淨重裝:先備份 profiles 目錄,卸載後手動刪掉殘留的資料目錄,再從下載頁取得目前版本安裝,裝好後把備份的訂閱檔案匯回去。不同用戶端之間的穩定性與功能差異,可參考選型指南換一個用戶端交叉驗證。

崩潰規律的記錄方法

偶發崩潰最難查,建議記三樣東西:崩潰前在做什麼操作、當時開沒開 TUN、日誌檔案最後二十行。帶著這三樣資訊,無論是自查還是向社群求助,效率都高一個量級。

九、行動裝置專項(Android / iOS)

Android:VPN 授權與背景存活

Android 用戶端(首推 Clash Plus,備選見下載頁 Android 區)透過系統 VPN 介面接管流量,首次啟動必須同意「建立 VPN 連線」的系統彈出視窗;當時拒絕了的,去「系統設定 → 網路 → VPN」裡刪除該應用程式的條目再重新授權。連線圖示(狀態列鑰匙/VPN 標誌)在、但流量不走,則檢查用戶端內的分應用程式代理設定——黑名單模式下被排除的應用程式、白名單模式下沒勾選的應用程式,都不會經過代理。

「用著用著斷了」幾乎都是系統省電機制關閉背景程式:台灣本地常見的定制系統與大陸品牌手機(MIUI、ColorOS、HarmonyOS 等)預設會積極回收背景行程。處理三件套:把用戶端加入電池最佳化白名單(設為「不受限制」)、在多工介面鎖定該應用程式、允許自動啟動。三項都設定後仍頻繁斷線,在用戶端裡開啟「常駐通知」類選項提高行程優先順序。

iOS:Network Extension 的記憶體限制

iOS 用戶端經 App Store 發布,首推 Clash Plus(下載頁 iOS 區直接提供商店連結)。iOS 的代理運行在 Network Extension 裡,系統對這個擴充行程有嚴格的記憶體上限——訂閱裡節點數量過多、規則集過大時,擴充行程會被系統直接終止,表現為「VPN 圖示出現一兩秒就消失」或頻繁自動斷線。處理辦法:請服務商提供精簡版訂閱,或用轉換服務裁掉用不到的地區節點與冗餘規則集,把設定體積壓下來;規則模式下優先用 GEOIP/GEOSITE 這類精簡規則,少用幾萬行的純文字清單。

另一個 iOS 常見現象:切換 Wi-Fi 與行動網路後短暫無網路。這是 VPN 通道隨網路切換重建的過程,等待幾秒即可;長期不恢復就在用戶端裡手動重新連線一次。

行動網路與 Wi-Fi 的行為差異

同一支手機,Wi-Fi 下正常、行動網路下節點全超時(或反過來),表示其中一個網路對代理流量有干擾,與用戶端無關:電信業者網路可能封鎖特定連接埠或協定,公共 Wi-Fi 可能有強制入口網站與攔截。用這個差異做交叉驗證,可以快速把問題歸到「網路環境」而不是浪費時間重裝應用程式。行動裝置首次安裝的完整流程與權限設定順序,部落格裡有整篇梳理:Clash 用戶端首次安裝全流程。

十、規則命中校驗與設定回滾

還有一類問題不表現為「斷網」,而是「走錯了出口」:本地站點繞道境外導致變慢、境外站點被判定直連而打不開、某個應用始終不走代理。這類症狀排查的關鍵不是重新安裝,而是確認某條流量實際命中了哪條規則,以及這條規則是誰寫進設定的。

用日誌確認實際命中的規則

把日誌等級調到 info 後存取目標站點,日誌會給出「網域 → 命中規則 → 出口分組」的完整鏈路。若命中的是兜底規則 MATCH,說明前面所有規則都沒匹配上,應檢查網域寫法是否用了通用字元前綴、規則類型是否與實際請求形態對應(瀏覽器發出的是網域請求,應用直連 IP 時只有 IP 規則能命中)。若命中了一條你並不認識的規則,基本可以確定來自訂閱自帶的規則集,需要在自訂段落裡用更靠前的規則覆蓋它——Clash 規則自上而下匹配,先命中者生效,順序比數量重要得多。

規則不生效的三種常見成因

• 順序被搶:自訂規則寫在訂閱規則集之後,前面已經命中,後面的永遠不會執行;把自訂段落整體提到規則列表最前端。
• 類型選錯:用 DOMAIN-SUFFIX 去匹配一個只有 IP 的連線,或用 IP-CIDR 匹配尚未解析的網域請求;涉及 IP 的規則需要留意 no-resolve 參數是否該加。
• 分組指向錯誤:規則本身命中了,但目標分組當前選中的節點是「直連」或一個不可用節點;在代理頁確認該分組的實際選中項,而不是只看規則文字。

改壞了怎麼快速回滾

每次改設定前複製一份原始檔案並加上日期後綴,這是成本最低的保險。改完先用用戶端的設定校驗或重新載入功能確認 YAML 語法通過——縮排錯一格、全形冒號混入半形冒號,都會讓整份設定載入失敗並退回上一次可用狀態。若用戶端已經處於載入失敗、介面空白的狀態,直接把備份檔案改回原名重新載入即可;實在沒有備份,就刪掉自訂段落只保留訂閱原始設定,先恢復可用,再逐條加回改動,每加一條驗證一次,這樣才能定位到究竟是哪一行引起的問題。