為什麼用戶端會啟動即崩潰
Clash 系用戶端(包括 Clash Verge、Clash Meta 用戶端、基於 mihomo 核心的各類圖形介面殼)在結構上分兩層:上層是負責介面、系統匣、訂閱管理的用戶端行程,下層是真正做流量轉發的核心行程(通常是 mihomo 或其前身 Clash Premium)。啟動崩潰可能發生在任意一層,原因也完全不同——用戶端介面行程崩潰往往是安裝損毀、依賴庫缺失或系統權限問題;核心行程崩潰則幾乎總能追溯到設定檔、埠號佔用或殘留行程這三類原因之一。
在動手重灌之前,先弄清楚是「介面打不開」還是「介面能打開但一點連線就退出」或「開機自動啟動後瞬間消失」。這三種表現對應的排查路徑完全不同,盲目卸載重灌往往解決不了根本問題,下次更新照樣復發。
第一步:看日誌,別猜
幾乎所有崩潰情境第一手線索都在日誌裡,跳過這一步直接搜尋「閃退怎麼辦」只會浪費時間。日誌通常分兩處:用戶端自身的執行日誌,以及核心輸出的連線日誌。
- Windows:用戶端日誌一般存放在使用者目錄下的
AppData\Roaming或AppData\Local對應產品名稱的資料夾裡,子目錄名稱通常包含logs;核心日誌則在設定目錄的logs子資料夾,按日期命名。 - macOS:用戶端日誌多落在
~/Library/Logs/下對應產品名稱的資料夾;也可以直接開啟「主控台」App,按行程名稱過濾,能看到崩潰時系統丟出的異常堆疊。
開啟最新一份日誌,重點找三類關鍵字:
yaml: line或unmarshal—— 設定檔語法或欄位型別錯誤;bind: address already in use—— 埠號被佔用;panic或fatal error—— 核心執行時崩潰,常伴隨一段呼叫堆疊。
把這段錯誤訊息原文複製下來,後面三步基本就是照著錯誤類型對症處理,不需要把整份日誌都讀完。
time="2026-05-20T21:14:02+08:00" level=fatal msg="Parse config error: yaml: line 47: mapping values are not allowed in this context"上面這類錯誤說明問題就在設定檔第 47 行附近,通常是縮排錯了一格或者冒號後面多打了一個冒號,不用懷疑用戶端本身有問題。
第二步:清理快取與殘留核心行程
如果日誌裡沒有明顯的設定錯誤,但用戶端就是打開一半就消失,大概率是本地快取檔案損毀或者上一次未正常退出留下的殭屍核心行程占著資源不放。處理方式:
- 先用系統的工作管理員(Windows)或活動監視器(macOS)搜尋核心行程名稱(常見為
mihomo、clash-meta或clash),如果發現已有實例在執行,先手動結束它,再啟動用戶端。 - 關閉用戶端後,刪除設定目錄下的快取檔案(通常命名為
cache.db或類似字樣,不要刪除你的訂閱設定yaml檔案),這類快取檔案損毀是升級後閃退的常見原因。 - 如果用戶端有「重設面板快取」或「還原預設設定」選項,優先用介面內建的重設功能,比手動刪檔案更安全,不會誤刪訂閱資訊。
- 重新啟動用戶端,觀察是否恢復正常。
第三步:檢查埠號是否被佔用
Clash 系用戶端啟動時需要綁定幾個本地埠號:HTTP/Mixed 代理埠(常見預設值如 7890)、控制面板埠(常見預設值如 9090),以及開啟 TUN 模式時的虛擬網卡相關埠號。如果這些埠號已經被其他程式佔用,核心行程會直接啟動失敗,表現為用戶端介面一閃而過或者卡在「連線中」狀態。
排查方法:
- Windows:開啟命令提示字元,執行
netstat -ano | findstr 7890(把 7890 換成你設定裡實際使用的埠號),如果有輸出,說明該埠號已被佔用,記下最後一列的行程 PID,再到工作管理員裡找到對應行程決定是否關閉。 - macOS:開啟終端機,執行
lsof -i :7890,同樣能看到佔用該埠號的行程名稱和 PID。
常見的埠號衝突來源包括:同時裝了兩個 Clash 系用戶端(比如新舊版本沒卸乾淨)、系統上還執行著另一個代理工具、或者上一次核心行程沒有正常退出、殭屍行程仍占著埠號。確認衝突來源後,結束多餘行程,或者直接在設定檔裡把 port、external-controller 改成別的空閒埠號,儲存後重新啟動。
mixed-port: 7891
external-controller: 127.0.0.1:9091第四步:驗證設定檔語法
YAML 格式對縮排和冒號後面的空格極其敏感,手動改設定或者從不同來源拼接規則時,很容易引入語法錯誤。除了看日誌裡給出的行號,還可以用下面幾種方式提前自查:
- 檢查每一行冒號後面是否都跟了一個空格,YAML 規定
key: value之間必須有空格,寫成key:value會被當成一般字串解析失敗。 - 檢查縮排是否統一使用空格,不要混用 Tab 和空格,同一層級的縮排空格數必須完全一致。
- 檢查
proxy-groups裡引用的代理名稱是否在proxies清單裡真實存在,拼寫不一致會導致引用找不到目標,部分用戶端會直接崩潰而不是給出提示。 - 如果設定來自訂閱連結自動產生,先嘗試換用戶端內建的「設定驗證」或「語法檢查」功能跑一遍,大多數圖形介面用戶端在設定裡都提供這個入口。
如果排查到最後發現是訂閱方自己推送的設定本身有問題,可以先暫時切換到一份已知能正常運作的舊設定,確認用戶端本身沒問題後再聯繫訂閱方確認。
Windows 與 macOS 常見崩潰情境對照
| 現象 | Windows 常見原因 | macOS 常見原因 |
|---|---|---|
| 圖示點擊無反應,介面完全不出現 | 安裝目錄檔案被安全軟體誤刪或攔截,重新安裝並加入信任清單 | 應用程式未獲得「輔助使用」或「網路擴充功能」授權,系統設定裡手動允許 |
| 介面打開後幾秒內自動關閉 | 快取檔案損毀,或與舊版本殘留檔案衝突 | Gatekeeper 攔截未簽章元件,首次執行需在「隱私權與安全性」裡允許 |
| 點擊「連線」或載入訂閱後崩潰 | 設定檔語法錯誤或埠號被佔用 | 設定檔語法錯誤或埠號被佔用(與系統無關,兩端一致) |
| 開啟 TUN 模式後崩潰 | 虛擬網卡驅動程式未正確安裝,需以系統管理員權限重新安裝一次 | 系統擴充功能未獲核准,需要在「隱私權與安全性」裡手動允許後重新啟動 |
| 開機自動啟動後不見蹤影 | 自動啟動項目的啟動順序早於網路服務就位,核心綁定埠號失敗 | 登入項目權限不完整,建議刪除舊登入項目重新加入一次 |
還是沒解決?按這個順序兜底
如果以上四步都走完了問題依舊存在,按下面的順序做最後排查,通常能涵蓋絕大多數遺留情境:
- 確認下載的安裝包與系統架構相符,比如 Windows 上 ARM 裝置裝了 x64 版本,或者 macOS 上 Intel 晶片裝了僅支援 Apple Silicon 的建置版本,都會導致啟動異常。
- 完整卸載後手動刪除殘留的設定目錄(注意提前備份訂閱連結),再重新安裝最新版本,避免跨版本升級留下的欄位不相容問題。
- 暫時關閉安全軟體或防火牆做一次對照測試,如果關閉後能正常啟動,說明是安全軟體的即時防護攔截了核心行程,需要把用戶端加入白名單。
- 如果是透過第三方管道下載的安裝包,建議改用官方下載管道重新取得一份,避免安裝包本身被竄改或損毀導致的運作異常。