一、先確認消失的是視窗,還是代理核心
視窗消失,不一定代表程式當機。Clash 類用戶端通常包含圖形介面和代理核心兩部分:前者負責按鈕、設定清單和選項,後者負責實際接收連線並執行規則。mihomo 是部分用戶端採用的代理核心,也常稱為 Clash Meta。兩部分可能各自發生問題,排查時請先確認是哪一部分出狀況。
- 查看系統匣是否還有用戶端圖示。Windows 的圖示可能藏在工作列的隱藏圖示區;如果圖示仍在,先從系統匣重新開啟主視窗,確認是否設定了啟動後最小化。
- 按 Ctrl + Shift + Esc 開啟工作管理員,在「詳細資料」中查看用戶端及其核心處理程序。記下處理程序名稱,不要只憑圖示判斷。
- 如果視窗能開啟,但顯示核心未執行,請優先查看核心日誌;如果圖形介面處理程序也立即消失,則先查看用戶端日誌和系統當機記錄。
- 先結束其他代理用戶端,再啟動一次發生問題的用戶端。兩套程式同時執行,可能會搶用本機連接埠或虛擬網卡。
二、找出日誌:保留啟動前後的第一筆錯誤
日誌位置取決於用戶端,而不是「Clash」這個統稱。安裝資料夾、使用者資料資料夾和核心工作目錄可能各在不同位置。不要從網路上複製某個資料夾路徑,就認定自己的日誌一定在那裡。
視窗還能停留幾秒時
優先使用用戶端設定中的「開啟日誌資料夾」或「開啟設定資料夾」功能;名稱和位置會因用戶端而異。開啟後複製整個日誌資料夾,並記下啟動時間,例如 09:42:10。接著重新啟動一次,查看該時間之後新增的日誌,不要反覆查看上次留下的舊錯誤。
視窗完全無法開啟時
- 舊版 Clash for Windows:常見的資料位置是
%USERPROFILE%\.config\clash,可檢查其中是否有logs資料夾。若使用可攜模式或曾移動資料夾,請以檔案的實際修改時間為準;其他用戶端不要套用這個路徑。 - 其他 Windows 用戶端:在檔案總管網址列分別輸入
%APPDATA%和%LOCALAPPDATA%,依用戶端名稱或專案識別名稱尋找資料夾。先查看並備份,暫時不要刪除。 - Windows 系統記錄:按 Win + R,輸入
eventvwr.msc,前往「Windows 記錄」→「應用程式」,尋找啟動時的錯誤。也可執行perfmon /rel,在可靠性監視器中查看應用程式故障。 - macOS:開啟「主控台」查看當機報告;使用者層級的報告通常位於
~/Library/Logs/DiagnosticReports。如果只有核心退出,仍應優先尋找用戶端自己的核心日誌。 - Linux:從終端機啟動用戶端實際的執行檔,保留終端機輸出;若使用 systemd 使用者服務,再查看對應的服務日誌。不要假設所有發行版都使用相同的服務名稱。
查看日誌時,先找出第一筆導致啟動中斷的錯誤,再檢查前後各 20 行。最後出現的「連線遭拒」可能只是核心已經退出的結果。故障模組指向圖形執行環境,也不能直接證明是顯示卡驅動程式的問題,還需要搭配用戶端日誌判斷。
| 日誌線索 | 優先檢查項目 | 下一步 |
|---|---|---|
address already in use | 監聽連接埠遭占用 | 查出占用的處理程序,先別急著重新安裝 |
yaml、unmarshal | 設定結構或欄位型別 | 測試實際載入的設定檔 |
no such file、not found | 核心或必要資源不存在 | 確認錯誤路徑和安裝內容 |
permission denied | 資料夾、執行權限或服務權限 | 檢查目前帳戶與資料夾權限 |
access is denied | 權限、連接埠排除範圍或安全防護攔截 | 依完整錯誤訊息判斷,不能一概視為連接埠遭占用 |
三、連接埠遭占用:找出 7890 和 9090 的使用者
連接埠衝突通常會影響核心啟動,不一定會讓整個介面閃退。7890 常用作本機代理連接埠,9090 常用作控制介面連接埠,但兩者都可以修改。請以日誌和目前設定為準;如果錯誤訊息顯示 7897,就查詢 7897。
在 Windows PowerShell 中執行以下命令,查看範例連接埠的 TCP 監聽程序。沒有輸出只代表查詢當下沒有對應的監聽程序,無法排除相關程序剛好已退出。
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess
假設輸出中的處理程序編號是 4321,再查詢該處理程序的資訊。4321 僅為示範數值,執行時請換成查詢到的編號。
Get-Process -Id 4321 | Select-Object Id,ProcessName,Path
- 如果占用連接埠的是另一套代理工具,請從該工具的系統匣選單正常退出,避免直接終止不明的系統處理程序。
- 如果占用連接埠的是同一用戶端留下的核心,請先退出用戶端及其背景服務,確認沒有連線正在使用後,再處理殘留的處理程序。
- 如果確實需要同時使用兩套程式,可以將其中一套的代理連接埠改為未占用的
7893,控制連接埠改為未占用的9093。也要更新應用程式中手動填寫的代理位址,不能只改設定而保留舊連接埠。
如果沒有監聽程序,但 Windows 顯示連接埠存取遭拒,可以使用 netsh interface ipv4 show excludedportrange protocol=tcp 查看 TCP 排除連接埠範圍。不要直接刪除系統保留範圍,請改用範圍以外的空閒連接埠。若是 UDP 綁定錯誤,則需另外檢查 UDP 端點,不能只憑 TCP 查詢下結論。
四、還原設定:先測試 YAML,再檢查用戶端合併設定
還原設定時應恢復整份可用設定,不要隨意刪除欄位。YAML 是以縮排表示層級的文字格式。混入定位字元、數字型別錯誤,或引用不存在的策略群組,都可能導致設定載入失敗。成功下載訂閱內容,也不代表下載的內容一定適用目前的核心。
依最近一次變更縮小排查範圍
- 剛手動編輯過設定:先複製故障檔案留存,再還原修改前的備份。
- 剛更新過訂閱:保留更新後的檔案;如果用戶端有儲存歷史快照,先還原到先前能啟動的版本。訂閱內容也可能由伺服器端變更。
- 剛更換過核心:檢查設定是否包含只有新核心才支援的欄位或通訊協定。傳統 Clash 與 mihomo 支援的範圍不同,不能只因為「都是 YAML」就認定相容。
- 剛啟用覆寫或指令碼:覆寫是用戶端在原始設定上新增或取代欄位的程序。請暫時停用新增的合併設定,再測試原始設定。
使用目前的核心測試設定
mihomo 的 -t 用來測試設定後退出,-f 用來指定設定檔,-d 用來指定工作目錄。以下假設已將目前用戶端搭配的核心和待測設定放入 D:\ClashRecovery,檔名分別為 mihomo.exe 和 candidate.yaml;若實際路徑不同,請相應調整。
Set-Location 'D:\ClashRecovery'
.\mihomo.exe -t -d 'D:\ClashRecovery' -f 'D:\ClashRecovery\candidate.yaml'
工作目錄可能還需要地理資料或規則資源。如果提示缺少資源,應先補齊與目前設定相符的資源,不要直接認定是縮排錯誤。測試通過只代表該核心可以載入這份設定,不保證節點能連線、遠端規則能下載,更不保證圖形介面一定正常。
五、核心遺失、架構不符與執行環境錯誤
只有日誌明確指出檔案或載入失敗時,才處理程式檔案。「核心未執行」也可能是設定錯誤造成,不代表核心檔案遺失。請先核對錯誤訊息中的完整路徑,再檢查檔案是否存在、是否曾被移動,以及目前使用者是否有讀取和執行權限。
確認安裝檔與裝置架構相符
在 Windows 中前往「設定」→「系統」→「系統資訊」查看系統類型;Linux 可執行 uname -m。請依裝置架構及用戶端支援情況選擇 x64 或 ARM64 安裝檔。不要直接把另一款用戶端的核心改名覆蓋,因為啟動參數、控制介面和配套資源可能不同。
依安全性記錄與相依性提示處理
- 在 Windows 中開啟「Windows 安全性」→「病毒與威脅防護」→「保護歷程記錄」,確認是否有相關檔案遭隔離的記錄。請先核實檔案來源和偵測詳細資訊,不要為了啟動程式而全面關閉防護。
- 如果日誌明確指出缺少 WebView2 或其他執行階段,請依該用戶端的系統需求修復相應的相依元件。並非所有 Clash 用戶端都使用 WebView2,不必一次安裝所有執行階段套件。
- macOS 提示無法開啟 App 時,請先確認 App 支援目前的系統版本,再查看「系統設定」→「隱私權與安全性」中的具體說明。不要照抄停用系統安全機制的命令。
- Linux 出現執行權限錯誤時,先用
ls -l查看目標檔案的權限;確認檔案來源和路徑後,再依專案安裝說明調整權限。
如果一般模式可以啟動,只有啟用 TUN 才失敗,就應改查虛擬網卡、服務安裝狀態和權限。請暫時關閉 TUN 進行比對;不要把「一律以系統管理員身分執行」當成所有閃退問題的通用解法。
六、安全重新安裝:分開確認程式與使用者資料
重新安裝前先保留資料,安裝後不要立刻全部還原。只覆蓋安裝檔案,可能會保留造成故障的使用者設定;直接刪除整個資料目錄,又可能遺失本機規則和訂閱記錄。較穩妥的方式是先備份、隔離,再逐項還原。
- 記錄目前狀況:記下用戶端名稱和版本、核心版本、作業系統版本、上次成功啟動的時間,以及最近執行的更新或設定變更。
- 備份資料:等程式和相關服務完全退出後,複製設定、訂閱記錄、本機規則、覆寫指令碼和日誌。備份中若含有憑證,請存放在受保護的本機資料夾。
- 隔離舊資料夾:確認實際的使用者資料資料夾後,將它重新命名為附有日期的備份資料夾,例如在原名稱後加上
-backup-20261015。如果資料夾仍被占用,請先處理背景處理程序,不要強行刪除。 - 重新安裝:依用戶端文件解除安裝程式;若使用服務模式,請依專案說明解除安裝對應服務。安裝符合裝置架構的穩定版本,不要混裝不同專案的程式檔案。
- 先以空白設定啟動:確認新執行個體使用新的資料資料夾,且未還原舊訂閱、指令碼和 TUN 設定,然後開啟視窗。部分用戶端在未選取設定時不會啟動核心,這和介面閃退是兩回事。
- 逐項還原:先匯入一份已知可用的設定,啟動並查看日誌;接著再還原本機規則、覆寫、系統 Proxy 和 TUN。每次只變更一項,方便找出問題的觸發條件。
如果使用空白資料仍會閃退,排查重點應轉向系統相容性、執行階段、安裝完整性或用戶端本身的缺陷。如果空白資料正常,還原舊資料後才重現問題,請保留新資料夾,分批還原舊內容,不要直接用整份備份覆蓋。
七、修復後的驗證與求助資訊
看得到視窗只是第一步,還要確認設定和連線都已恢復。讓用戶端保持開啟 2 分鐘,查看核心是否反覆重新啟動;確認目前選取的設定、代理模式和策略群組是否正確。規則模式會依規則選擇連線方式,因此特定網站直連不一定代表代理失效。
- 確認實際監聽的連接埠與應用程式填寫的代理連接埠一致,尤其是排查過程中曾修改 7890 的情況。
- 開啟連線清單,造訪一個有明確匹配規則的測試網域,查看套用的規則和策略群組,不要只看延遲數字。
- 如果需要使用 TUN,請最後再啟用,並檢查 DNS 解析、一般網頁和日常使用的應用程式。若出現異常,請還原到上一個已確認正常的狀態。
- 退出用戶端後再正常啟動一次;確認設定選擇和連接埠設定都能保留,且日誌沒有再次出現相同的啟動錯誤。
整體排查流程可以很簡單:先確認退出的是哪個部分,再查看日誌;出現連接埠錯誤就查連接埠,設定錯誤就還原設定,檔案錯誤再處理安裝。每一步都保留可還原的備份,通常比不斷重新安裝更容易找到真正的問題原因。