Clash 客戶端一開就閃退？啟動崩潰排解與修復指南

先分辨是介面退出、核心退出，還是視窗隱藏

Clash 客戶端通常由圖形介面、代理核心及可選的背景服務組成。介面消失不一定代表核心崩潰；所有節點逾時，也不代表客戶端閃退。先判斷是哪一層退出，再處理設定，才能避免反覆重新安裝，卻留下相同的故障原因。

Windows 可按 Ctrl + Shift + Esc 開啟工作管理員，在「詳細資料」中查看客戶端與核心程序。macOS 可開啟「活動監視器」，搜尋客戶端名稱及 mihomo。Android 則前往「設定」→「應用程式」→選取對應客戶端，分辨是應用程式退出還是 VPN 連線中斷；各品牌系統的選單名稱可能略有不同。

先備份設定，再找出第一個錯誤

保留訂閱與本機修改內容

先完全退出客戶端及其背景服務，再備份設定資料夾。請特別保留訂閱網址、本機 YAML、覆寫片段、規則集及策略群組選擇紀錄。設定資料夾位置依客戶端而異，不要把某個產品的路徑套用到所有 Clash 客戶端。若能開啟介面，優先使用客戶端提供的「開啟設定資料夾」或「開啟日誌資料夾」功能。

若介面無法開啟，可查看安裝說明及系統的應用程式資料夾。Windows 常見位置在 %APPDATA% 或 %LOCALAPPDATA% 底下的應用程式子資料夾；macOS 通常位於 ~/Library/Application Support/。不要直接刪除這兩個上層資料夾。Android 的應用程式私有資料通常無法透過一般檔案管理器讀取，清除儲存空間前，請先確認訂閱與本機設定已另行備份。

依時間查找日誌，不要只看最後一行

• Windows：按 Win + R，輸入 eventvwr.msc，前往「Windows 記錄」→「應用程式」。找出退出時間附近的 Application Error、.NET Runtime 或 Windows Error Reporting 記錄，並保存故障應用程式、模組與例外代碼。
• macOS：開啟「主控台」查看崩潰報告，也可檢查 ~/Library/Logs/DiagnosticReports/。保留例外類型、終止原因與崩潰執行緒資訊。
• Android：熟悉 ADB 的使用者可啟用 USB 偵錯，再用以下命令記錄一次啟動過程。清空緩衝區會移除舊日誌，只有不需保留舊記錄時才執行。

adb logcat -c
adb logcat -v time > clash-startup.txt
# 請在此時於手機上啟動客戶端，重現退出後按 Ctrl+C 停止記錄

Android 日誌可優先搜尋 FATAL EXCEPTION、AndroidRuntime、Fatal signal 及應用程式套件名稱。桌面版則留意 permission denied、address already in use、panic 與設定解析錯誤。最後出現的「連線失敗」可能只是核心退出後的連帶提示，真正原因往往在更早的日誌中。

以最小設定確認 YAML 與核心是否相容

若異常是在更新訂閱、修改覆寫或升級核心後出現，先還原最近一次變更。訂閱來源檔案、客戶端覆寫內容與最終執行設定並非同一份檔案；應檢查核心實際載入的設定，而不只是訂閱編輯器中的內容。

先測試語法與載入狀況

以下命令適用於 mihomo，範例假設核心與設定檔位於同一個測試資料夾。請使用實際存在的核心檔案；其他 Clash 分支應先查看其 -h 說明，不能假設所有分支的參數都完全相同。

# Windows PowerShell
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

# macOS / Linux
./mihomo -v
./mihomo -t -f ./config.yaml

-t 用來測試設定能否通過載入檢查，不代表節點可連線，也不能取代實際啟動。若出現 YAML 行號錯誤，先檢查縮排是否混用定位字元、冒號後是否少了空格，以及策略群組參照的名稱是否存在。解析器可能到錯誤位置的下一行才停止，因此也要一併查看錯誤行前後的內容。

分別檢查訂閱、規則集與 TUN

備份後，在獨立的測試資料夾建立以下最小設定。這份設定僅用於確認核心能否啟動，所有流量都會直連，不包含任何代理節點。測試前請先退出原本的客戶端，避免同時啟動兩個核心。

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false
dns:
  enable: false
rules:
  - MATCH,DIRECT

使用 .\mihomo.exe -f .\minimal.yaml 或 ./mihomo -f ./minimal.yaml 在前景啟動，觀察程序是否持續執行，再按 Ctrl + C 結束。這裡使用 17890，是為了和常見的 7890 區分，並不保證該連接埠一定未被占用。測試期間不要啟用系統代理或 TUN。

1. 最小設定仍會退出：優先檢查核心架構、檔案權限、執行目錄及系統崩潰記錄。
2. 最小設定正常：逐一恢復節點、策略群組、規則集與 DNS，最後再啟用 TUN。
3. 只有恢復某個片段後才出現異常：保留該片段與完整錯誤訊息，檢查所需核心功能及設定格式。

Clash、Clash Meta 與 mihomo 支援的設定功能並不完全相同。欄位遭忽略或拒絕載入，都可能造成行為差異；YAML 格式正確，不代表設定一定適用於目前的核心。使用 proxy-providers、rule-providers 時，也要檢查檔案路徑、遠端回應內容及讀寫權限。

檢查代理連接埠、控制連接埠與殘留程序

address already in use 表示監聽地址已被占用。代理監聽連接埠與控制介面連接埠用途不同：例如 mixed-port: 7890 用於 HTTP/SOCKS 代理，external-controller: 127.0.0.1:9090 則用於管理介面；這些只是常見設定值，實際情況請以目前載入的設定為準。

Windows 查詢占用連接埠的程序

netstat -ano | findstr ":7890"
netstat -ano | findstr ":9090"
# 範例：確認 PID 1234 對應的程序名稱
tasklist /FI "PID eq 1234"

查看本機地址與 LISTENING 狀態，再依 PID 找出對應程序；不要把遠端地址上的相同連接埠誤判成本機占用。若是上次執行後殘留的核心，先透過客戶端或相關服務正常結束；若屬於其他程式，應先判斷要保留哪個監聽服務，不要直接終止不熟悉的系統程序。

macOS 查詢監聽中的連接埠

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

若將代理連接埠從 7890 改為 17890，瀏覽器擴充功能、命令列環境變數及系統代理也必須一併更新。修改客戶端管理介面連接埠前，則要確認介面是否會自動同步；控制連接埠不一致時，可能顯示「核心未連線」，即使核心本身仍在執行。

依 Windows、macOS 與 Android 修復執行環境

Windows：先確認故障模組，再處理執行階段

若日誌指向介面執行環境，請依客戶端的發布說明安裝對應相依元件。例如，使用 WebView2 的客戶端需要可正常使用的 WebView2 Runtime，但並非所有 Clash 客戶端都依賴它。只有缺少 DLL 或發布說明明確要求時，才處理相應的 Visual C++ 執行階段；不要從不明網站單獨下載 DLL 並放入系統資料夾。

查看 Windows 安全性中的「病毒與威脅防護」→「保護歷程」，確認核心是否遭隔離。先核實安裝檔來源與警示內容，不要長期關閉安全防護來解決問題。介面初始化與設定解析通常不需要系統管理員權限；只有安裝服務或啟用 TUN 等明確需要權限的步驟，才以系統管理員身分執行。

macOS：分辨 Intel、Apple Silicon 與權限提示

在「關於這台 Mac」確認處理器：Apple 晶片優先選擇 arm64 版本，Intel 處理器則選擇 x64 版本。系統顯示「無法打開」的安全性提示，與啟動後崩潰是兩種不同問題。若應用程式來源可信，可依「系統設定」→「隱私權與安全性」中的系統提示處理；不要批次移除所有應用程式的安全屬性。

若報告中出現 dyld、動態程式庫遺失或架構不相容，優先重新安裝符合系統的完整應用程式，而不是從另一台電腦複製核心。若是 TUN 相關異常，先關閉其他 VPN，再依客戶端文件檢查輔助服務的授權。

Android：分開排查啟動閃退與背景中斷

使用 adb shell getprop ro.product.cpu.abilist 可查看裝置支援的 ABI。請依裝置與客戶端支援情況選擇 arm64、armv7 或通用安裝檔；APK 使用的 ABI、應用程式要求的最低 Android 版本，以及裝置實際的系統版本都必須相符。

先前往「設定」→「應用程式」→選取客戶端→「儲存空間與快取」，嘗試清除快取。清除儲存空間會刪除本機設定，請先備份再操作。若 VPN 只在鎖定螢幕幾分鐘後中斷，應檢查電池最佳化及背景執行權限；這與點選圖示後立即出現崩潰提示是不同類型的問題。同一個 Android 使用者通常只能啟用一項 VPN 服務，測試前請先中斷其他 VPN 應用程式。

重新安裝核心與還原舊版的正確順序

只有在最小設定仍無法啟動、核心檔案遺失，或升級後穩定重現退出時，才進行重新安裝或還原版本。任意替換核心可能破壞客戶端與控制介面之間的相容性；不要把任何 mihomo 執行檔改名後塞進安裝資料夾。

1. 保留現況：匯出日誌並備份設定，記下目前的客戶端與核心版本，不要覆蓋唯一可用的安裝檔。
2. 停止相關程序：退出系統匣程式，依客戶端文件停止輔助服務，並確認監聽連接埠已釋出。
3. 還原相依元件：優先使用客戶端內建的核心還原功能；若介面無法啟動，請重新安裝同一版本的完整安裝檔。
4. 隔離舊資料：先備份，再將應用程式自己的資料資料夾重新命名保留，讓客戶端建立新的資料夾。不要刪除整個系統應用程式資料目錄。
5. 先測試全新環境：不要匯入舊覆寫，也不要啟用自動啟動或 TUN；確認介面與核心都能持續執行。
6. 逐項還原：先匯入一份確認可用的設定，再依序還原 DNS、規則集與 TUN。每次只變更一項，並記錄結果。

若新版本在全新資料資料夾中仍穩定重現問題，而同一裝置上的前一版運作正常，才有較充分的理由懷疑是版本回歸。還原版本時，請使用來源可信且符合系統架構的安裝檔，並留意新版資料格式是否能由舊版讀取；必要時分別使用獨立資料資料夾測試。

修復後檢查與回報問題清單

修復完成後，不能只確認「視窗能開啟」。建議依序檢查：介面保持開啟、核心完成初始化、代理連接埠開始監聽、設定匯入成功、規則模式可正常使用，最後才啟用 TUN。每個步驟都要確認日誌沒有反覆啟動或退出，再進行下一步。

• 正常退出後重新啟動一次，確認是否仍載入正確的設定。
• 重新啟動系統後，測試服務權限與代理開關，確認不是只有手動啟動才正常。
• 提供客戶端版本、核心版本、作業系統版本與架構，並說明最近一次升級或設定變更。
• 附上已遮蔽敏感資訊的日誌、崩潰時間與最精簡的重現步驟，並說明最小設定是否也會觸發退出。

依序排查：先確認退出的是哪一層，再查看日誌；先還原設定，再檢查連接埠；先確認執行環境，最後才重新安裝相依元件。這樣既能保留現有規則，也能將「Clash 一開就閃退」縮小為可重現、可定位的具體問題。