Clash 客戶端一開就閃退：啟動當機的日誌判讀與修復方法

先釐清是視窗還是核心結束

Clash 客戶端開啟後立刻消失，不一定代表整個程式都當掉了。桌面客戶端通常包含圖形介面、代理核心，以及可能獨立執行的服務元件。視窗關閉後，系統匣圖示和核心程序可能仍在執行；也可能只有 mihomo 核心啟動失敗，介面本身仍正常顯示。先確認是哪個部分退出，再選擇相應的修復方式。

啟動前記下四項資訊

• 客戶端名稱與完整版本號：能開啟介面時，請到「關於」頁面查看；否則查看安裝檔名稱或程式檔案內容。
• 作業系統版本與架構，例如 Windows 11 x64、macOS arm64；不要只寫「電腦版」。
• 故障發生時間，精確到分鐘；並記下此前是否更新客戶端、匯入訂閱或啟用 TUN。
• 退出前顯示的完整訊息，以及系統中是否還有客戶端、mihomo 或相關服務程序。

取得啟動日誌與系統當機紀錄

不同 Clash 客戶端的應用程式資料目錄並不相同，不能把某個客戶端的日誌路徑當成通用標準。若介面還能開啟，先查看「日誌」頁面，或在「設定」中尋找開啟日誌目錄、應用程式目錄的選項；名稱會因客戶端版本而異。請保存故障時間前後約一分鐘的內容，而不只是截取最後一行「啟動失敗」。

Windows：事件檢視器與應用程式資料

1. 按下 Win + R，輸入 eventvwr.msc。
2. 前往「Windows 記錄」→「應用程式」，找到故障時間附近的紀錄。應用程式當機常見的事件來源是 Application Error，事件識別碼為 1000，但不是每次退出都會留下這筆紀錄。
3. 記下故障應用程式名稱、故障模組、例外狀況代碼與程式路徑。程式路徑有助於確認啟動的是新安裝版本，還是舊版捷徑。
4. 在檔案總管分別輸入 %APPDATA% 與 %LOCALAPPDATA%，依客戶端名稱或專案識別碼尋找對應目錄。日誌可能位於應用程式子目錄的 logs 資料夾，也可能存放在介面指定的位置。

也可以執行 perfmon /rel 開啟可靠性監視器，依日期查看應用程式失敗紀錄。系統報告適合用來定位圖形介面當機；核心日誌則較適合判斷 YAML、連接埠與資源載入問題，兩者不能互相取代。

macOS：診斷報告與主控台

在 Finder 選擇「前往」→「前往檔案夾」，輸入 ~/Library/Logs/DiagnosticReports/。尋找與客戶端程序名稱及故障時間相符的 .ips 或 .crash 檔案。應用程式自己的日誌也可能位於 ~/Library/Logs/ 或 ~/Library/Application Support/ 下的專屬目錄。開啟「主控台」後，可依程序名稱篩選錯誤，並保留例外狀況類型與退出原因。

Linux：終端機啟動與使用者日誌

從終端機執行實際安裝的客戶端命令，可查看雙擊啟動時被隱藏的標準錯誤輸出。桌面啟動命令可從對應 .desktop 檔案的 Exec 欄位確認。若程式或使用者服務有寫入 journal，可查看最近十分鐘的紀錄：

journalctl --user --since "10 minutes ago" --no-pager

應用程式資料常見於 ~/.config/、~/.local/share/ 或 ~/.local/state/ 下的專案子目錄，但實際位置由客戶端決定。系統使用 systemd 且保留當機資訊時，可執行 coredumpctl list 查看紀錄；沒有輸出不代表程式一定沒有當機。

設定語法錯誤：先驗證實際載入的檔案

若日誌出現 yaml、unmarshal 或設定解析行號，先檢查最近匯入或修改的 Profile。YAML 縮排使用空格，不要使用 Tab；同一層級的欄位應保持一致。訂閱下載成功不代表設定一定有效：失效連結可能回傳登入頁面、錯誤文字，或未經轉換的節點清單。

檢查縮排、型別與策略名稱

• mixed-port: 7890 是數值欄位的範例。使用全形冒號或縮排層級錯誤都可能導致解析失敗。
• 清單項目需要正確的 - 前綴。若把 rules 寫成一般字串，可能會發生型別轉換錯誤。
• 規則引用的策略名稱應與設定中的代理或代理群組一致。例如規則使用 Proxy，但設定中只有 PROXY，就需要核對實際名稱。
• 檢查重複欄位，以及新增的合併、覆寫設定。原始訂閱即使正確，合併後的執行設定仍可能出錯。

使用 mihomo 的 Clash 客戶端，可在確認核心來源與版本後，測試設定副本。以下假設終端機目前所在目錄已有 config.yaml，且 mihomo 可直接執行：

mihomo -v
mihomo -t -f ./config.yaml

若核心不在 PATH 中，應使用客戶端實際核心的完整路徑，不要另外下載不同版本的核心來代替驗證。部分設定需要在指定工作目錄載入規則資源或資料庫；此時可用 -d 指定已確認的工作目錄。測試輸出應區分語法錯誤、策略引用錯誤與資源讀取失敗。

客戶端可能會依據 Profile、全域覆寫與介面設定產生最終執行設定。因此，原始訂閱測試通過後，還要檢查實際載入的檔案是否有錯。最有效的比對方式是還原修改前的備份，並保持客戶端版本不變後重新啟動。不要為了測試而永久刪除訂閱或規則。

核心檔案遺失：檢查安裝內容與安全性紀錄

若出現 no such file or directory、找不到可執行檔，或建立核心程序失敗，請檢查日誌指出的實際路徑。更新中斷、直接移動程式目錄、只複製主程式，或安全軟體隔離了某個元件，都可能造成安裝不完整。圖形介面檔案存在，不代表核心與相依元件都已備妥。

1. 檢查捷徑目標與安裝位置，確認不是從舊的解壓縮目錄啟動。
2. 確認核心檔案存在，並確認安裝檔的架構與系統相符。Linux 的 Exec format error 通常表示可執行檔格式或架構不相容。
3. 在 Windows 開啟「Windows 安全性」→「病毒與威脅防護」→「保護歷程記錄」，確認是否有與故障時間相符的隔離事件。
4. 從原專案的發布頁面重新下載完整安裝檔，退出客戶端後進行修復或重新安裝。保留應用程式資料備份，不要混用不同版本的零散檔案。

若 Windows 錯誤涉及 WebView2Loader.dll 或執行階段初始化，問題可能出在圖形介面的執行環境，而不是 YAML。只有相依於 WebView2 的客戶端才需要對應執行階段；其他客戶端不適用相同處理方式。請依客戶端發布說明修復相依元件，不要從陌生網站單獨下載 DLL 並放入系統目錄。

macOS 的系統安全性攔截通常會顯示明確提示，與毫無提示的當機不同。請先確認應用程式來源、系統相容性需求與診斷報告。不要把關閉 Gatekeeper 或大量移除應用程式安全屬性當成一般排查的第一步。

權限不足：分開檢查目錄與 TUN

permission denied 和 access is denied 表示操作遭拒，但不代表「任何情況都要以系統管理員身分執行」。一般設定檔讀寫與 TUN 虛擬網卡涉及不同權限：前者取決於檔案擁有者和目錄權限，後者則可能需要提權服務、系統網路延伸功能或裝置存取權限。

目錄無法讀寫

先查看日誌中的具體檔案路徑。若設定檔放在唯讀媒體、受保護目錄或同步資料夾中，客戶端可能無法寫入快取與資料庫。在 Linux 上曾用 sudo 啟動圖形客戶端，可能導致應用程式資料由 root 擁有；應檢查該目錄的擁有者，而不是遞迴放寬整個使用者目錄的權限。不要使用 chmod -R 777 作為修復方式。

TUN 或服務元件啟動失敗

1. 先還原啟用 TUN 前的設定，確認圖形介面與一般代理能正常運作。
2. 依照目前客戶端的文件安裝或修復服務元件，再使用介面提供的 TUN 開關。
3. 檢查系統是否提示需要授權、網路延伸功能遭封鎖，或服務無法啟動，並保存相關錯誤資訊。
4. 一次只啟用一個需要接管系統路由的工具，避免多個虛擬網卡與路由管理程式同時介入。

殘留程序與連接埠占用：先確認程序歸屬

更新後舊核心仍在執行，可能占用新核心需要監聽的連接埠。日誌中的 address already in use 比「啟動失敗」更有助於定位問題。代理監聽連接埠與外部控制介面連接埠不同：7890、9090 只是常見設定範例，排查時請以實際設定與錯誤訊息中的連接埠為準。

查看連接埠所屬程序

在 Windows 命令提示字元執行以下命令，查看最末欄的 PID，再到「工作管理員」→「詳細資料」核對程序名稱與可執行檔路徑：

netstat -ano | findstr ":7890"
netstat -ano | findstr ":9090"

輸出結果也可能包含符合條件的遠端位址，請確認本機位址、連接埠與監聽狀態。macOS 可查詢 TCP 監聽程序：

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

Linux 可查看監聽中的通訊端；程序資訊可能受權限限制，一般使用者不一定看得到其他使用者的程序：

ss -lntp 'sport = :7890'
ss -lntp 'sport = :9090'

1. 優先從系統匣退出舊客戶端；獨立服務則依其安裝方式停止，不要只關閉視窗。
2. 再次查詢連接埠，確認監聽已停止，再啟動目標客戶端。
3. 若占用連接埠的是另一項必要服務，可調整目標客戶端的連接埠，並同步更新系統代理與相關應用程式設定。
4. 確認程序歸屬後才結束程序。不要只因為「名稱看起來像代理」就大量終止系統或網路元件。

連接埠遭占用通常會導致核心啟動失敗，不一定會讓圖形介面直接當掉。如果釋放連接埠後視窗仍立即退出，應回頭查看系統當機報告，而不是反覆更換連接埠。

先備份再重設：分階段還原設定

日誌不足以定位問題，或舊設定與新版本不相容時，可使用乾淨的應用程式資料進行對照測試。重新安裝不一定會重設設定，因為應用程式資料通常與安裝目錄分開存放。重設前務必確認目前客戶端使用哪個目錄，以免誤動到其他客戶端的資料。

1. 停止程式。退出系統匣中的客戶端，並確認核心或服務已停止寫入資料。
2. 完整備份。複製應用程式資料目錄，保留本機 YAML、訂閱資訊、覆寫規則與介面設定。備份含有敏感資訊，請存放在受控的本機位置。
3. 隔離舊資料。將已確認的應用程式資料目錄重新命名，例如在原目錄名稱後加上 .backup-20260917，不要直接刪除。
4. 以預設狀態啟動。確認客戶端能否建立新目錄並持續執行。此時先不要還原自動連線、TUN 或所有訂閱。
5. 逐項還原。先匯入一份已確認有效的設定，再還原覆寫規則，最後恢復 TUN 與服務設定。每個步驟都重新查看日誌。

若問題在還原某一步後再次出現，就能取得可重現的定位條件。若使用全新資料仍然當機，設定因素的可能性就較低，應檢查客戶端版本、執行階段相依元件與系統相容性。回退版本時也應使用獨立備份，避免舊版直接讀取新版遷移後的資料庫。

驗證修復結果與回報資訊

視窗能開啟只是第一項驗證。還要確認核心持續執行、設定載入成功，且監聽連接埠符合預期。使用系統代理時，請確認瀏覽器請求是否經過該連接埠；使用 TUN 時，則再檢查路由與 DNS 行為。節點逾時屬於連線層問題，不應只憑逾時就認定客戶端仍在啟動時當機。

• 完整退出後重新啟動一次，確認修復不依賴殘留程序。
• 保存修復前後的日誌，記錄調整項目是設定、安裝檔案、權限還是服務狀態。
• 回報問題時，請附上客戶端與核心版本、系統架構、重現步驟，以及已去除敏感資訊的關鍵錯誤。
• 若報告包含故障模組或例外狀況代碼，請原樣保留；不要只寫「打不開」或只附上視窗截圖。

排查順序可歸納為：確認退出的是哪個部分、取得日誌、依錯誤檢查設定、檔案、權限與連接埠，最後透過備份後重設進行比對。若需要重新選擇安裝檔，請前往客戶端下載頁；設定匯入與系統代理步驟請參閱使用指南，TUN 與 DNS 參數則見進階設定。