Clash 用戶端啟動閃退怎麼辦：從執行環境到設定檔復原的排查步驟

先釐清：視窗閃退、背景執行與核心退出

搜尋「Clash 打不開」時，首先要確認消失的是視窗，還是整個程序。Clash 系列用戶端負責介面、訂閱匯入與設定管理；Clash 或 Clash Meta（mihomo）核心則負責代理連線、規則比對及 DNS 處理。介面可能正常顯示，但核心無法啟動；核心也可能仍在執行，只是介面視窗已關閉。這兩種情況需要收集的日誌與修復位置不同。

啟動一次後觀察約 10 秒，檢查系統匣、活動監視器或工作管理員。不要連續雙擊程式：既有執行個體、背景服務與新的啟動要求混在一起，會讓連接埠占用情況與退出時間難以判斷。

操作前備份：保留設定、日誌與版本資訊

直接解除安裝可能保留損壞的使用者資料，也可能刪除尚未匯出的訂閱與覆寫設定；「重裝後還是閃退」不能據此證明安裝包有問題。先記下用戶端完整名稱與版本、核心版本、系統版本及架構，並標明故障是在更新用戶端、更新訂閱，還是修改設定後出現。用戶端版本與核心版本是兩項不同資訊，不能只寫「最新版」。

備份應包含哪些內容

• 原始設定與訂閱：儲存本機 YAML、訂閱紀錄及仍能正常運作的舊設定。訂閱 URL 通常包含存取憑證，應按照密碼保存。
• 覆寫與合併邏輯：分開儲存規則追加、設定合併片段與腳本。訂閱原文正確，不代表最後產生的執行設定正確。
• 用戶端設定：記錄系統代理、TUN、服務模式、本機監聽連接埠與控制介面設定，必要時擷取畫面。
• 故障日誌：保留啟動前後約 1 分鐘的紀錄，既要查看核心日誌，也要查看介面程序的錯誤。

如果介面能開啟，優先使用用戶端提供的開啟設定目錄、開啟日誌目錄或匯出功能；不同用戶端的選單命名並不一致。若完全無法啟動，再依該用戶端文件確認資料目錄。Windows 的 %APPDATA% 與 %LOCALAPPDATA%、macOS 的 ~/Library/Application Support/ 都只是可能的上層位置，不要刪除整個目錄，也不要把安裝目錄直接當成使用者資料目錄。

複製前先正常退出用戶端，確認相關程序不再寫入檔案；使用服務模式時，還需透過用戶端支援的服務管理入口停止對應服務。不要只憑程序名稱模糊比對後批次結束工作。準備分享日誌時，另製一份去識別化副本，遮蔽訂閱權杖、節點密碼、控制介面金鑰、私人網域與使用者名稱。

執行環境檢查：系統架構、相依元件與完整解壓縮

依裝置架構選擇套件，不要從檔名猜測

Windows 11 可在「設定」→「系統」→「系統資訊」查看「系統類型」；Intel 或 AMD 的常見桌上型裝置通常選擇 x64，ARM 裝置則應確認專案是否提供 ARM64 套件。macOS 可在蘋果選單「關於這台 Mac」查看「晶片」或「處理器」，區分 Apple Silicon 與 Intel。Linux 可使用 uname -m 查看架構，常見輸出 x86_64 與 aarch64 分別對應 x64 與 ARM64。

處理器架構相符還不夠，系統最低版本、Linux 的執行庫版本與桌面環境也可能有要求。若提示 Exec format error，優先檢查可執行檔架構；若明確提示 GLIBC_… not found，應核對發行版與程式建置要求，不要手動替換系統核心執行庫。Android 安裝包則需依裝置支援的 ABI 選擇，舊裝置不能只憑「64 位元處理器」就認定能執行任意 ARM64 應用程式。

相依元件必須符合特定用戶端的實作

• Windows WebView 介面：依賴 WebView2 的用戶端若提示執行階段缺失或初始化失敗，應依專案文件修復對應的執行階段。Electron 用戶端不是同一套相依元件，不能把安裝 WebView2 當成通用解法。
• DLL 缺失：只有錯誤或專案說明明確指向 Visual C++ 執行階段等元件時，才修復相應架構的執行庫；不要下載來源不明的單一 DLL 並放入系統目錄。
• 可攜版套件：先完整解壓縮至目前使用者可讀寫的本機目錄，再從解壓縮目錄啟動。在壓縮檔預覽中直接執行，可能遺失核心、資源或相鄰檔案。
• 系統攔截：查看 Windows「Windows 安全性」→「病毒與威脅防護」→「保護歷程記錄」，或 macOS「系統設定」→「隱私權與安全性」中的相關提示，確認遭攔截的具體檔案與原因，不要關閉整套系統防護。

在 Windows 上可透過 Win + R 輸入 eventvwr.msc，在「Windows 記錄」→「應用程式」中尋找啟動時刻附近的錯誤，記錄故障應用程式、故障模組與例外碼。這裡的模組資訊有助於區分介面繪製異常與核心退出，但單一模組名稱不足以直接判定根因。

權限與連接埠檢查：先關閉 TUN 縮小範圍

如果用戶端在啟用 TUN 或安裝服務後才出現問題，先在介面中關閉 TUN，再退出並啟動一次。TUN 用於在網路層接管流量，通常涉及系統授權、服務或虛擬網路介面；系統代理主要為遵循系統代理設定的應用程式提供代理入口，兩者不是同一個開關。一般介面啟動與僅監聽本機高位連接埠，通常不需要持續使用管理員權限。

若關閉 TUN 後能啟動，應繼續檢查用戶端服務狀態、系統 VPN 授權，以及其他 VPN 或虛擬網路介面軟體的衝突。Windows 服務模式應依目前用戶端文件修復服務；Android 的 VPN 授權或其他應用程式占用 VPN 槽位，應與應用程式介面閃退分開處理。不要直接刪除所有虛擬網路介面，也不要對整個資料目錄授予所有使用者寫入權限。

以本機連接埠 7890 為例檢查監聽衝突

日誌出現 address already in use 或 Windows 的 Only one usage of each socket address 時，先找出具體衝突的位址與連接埠。以下命令僅適用於設定確實使用 7890 的情況；若錯誤指向控制介面或 DNS 連接埠，應改查日誌中的連接埠。

# Windows PowerShell：尋找監聽 7890 的程序
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS：尋找 TCP 監聽程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看 TCP 監聽清單及程序資訊
ss -ltnp

根據輸出的程序識別碼確認占用者；Linux 一般使用者可能看不到其他使用者的完整程序資訊。若占用者是另一個代理用戶端，先正常退出它；若是目前用戶端遺留的服務，應透過對應管理入口處理。確實需要更換連接埠時，務必同步修改瀏覽器或系統代理入口，否則即使核心恢復，應用程式仍會連線至舊連接埠。

設定檢查：驗證核心實際讀取的 YAML

介面能開啟但核心反覆退出時，應從日誌中尋找第一則具體錯誤，而不是只看最後的「啟動失敗」。常見原因包括 YAML 縮排錯誤、規則指向不存在的策略群組、核心不支援節點類型，以及資源檔案不存在。Clash 與 mihomo 支援的欄位範圍不同，某個用戶端能匯入訂閱，不代表它所呼叫的核心能執行其中所有欄位。

先檢查合併結果，再檢查訂閱原文

1. 確認目前選取的設定檔，並從日誌或用戶端功能中找出實際執行的設定。
2. 檢查是否啟用了覆寫、腳本、規則追加或代理集合；暫時停用最近新增的處理步驟。
3. 檢查 YAML 是否使用空格縮排；核對策略群組名稱、規則目標與代理引用是否完全一致。
4. 區分訂閱下載失敗與設定解析失敗：返回登入頁或錯誤頁面的 URL，不能當作 YAML 交給核心解析。

使用 mihomo 且能夠執行其獨立可執行檔時，可以先進行設定測試。以下命令假設目前目錄內有名為 mihomo 的可執行檔及 diagnostic.yaml；Windows 假設檔名為 mihomo.exe。實際名稱應以所使用用戶端附帶的檔案為準，不要為了測試而任意替換用戶端核心。

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

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

-v 用於記錄核心版本，-t 用於測試設定。設定涉及相對路徑、代理集合或規則集合時，還應依核心說明使用 -d 指定對應工作目錄，否則可能因資源位置不同而產生額外錯誤。測試通過只表示該測試環境下設定檢查通過，不能保證連接埠可繫結、TUN 具備權限或遠端節點可連線。

使用最小直連設定隔離訂閱問題

以下是用於 mihomo 的診斷範例，不含代理節點，也不提供代理出口。僅在已完成備份、關閉系統代理與 TUN，並確認 7890 未被占用的前提下，作為獨立測試檔案使用。不要將它覆蓋至訂閱原始檔案；用戶端自動加入的覆寫設定也應暫時停用。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

若最小設定可啟動，而原設定不能，下一步逐項復原代理節點、策略群組、規則、DNS 與覆寫設定，找出首次失敗的變更。若最小設定仍出現相同的相依元件、權限或連接埠錯誤，應回到執行環境層面檢查。不要用切換 Fake-IP、修改 DNS 伺服器等網路參數來修復介面程序閃退。

設定復原：隔離舊資料，不要直接清空

當執行環境已核對、日誌指向本機設定讀取失敗，或更新後只有舊使用者資料會觸發異常時，可以進行資料目錄隔離測試。目的是判斷故障是否隨舊資料出現，而不是要求永久丟棄原設定。

1. 完成備份並退出：停止用戶端及其對應服務，確認沒有殘留程序繼續寫入。
2. 確認正確目錄：依目前用戶端文件定位資料目錄。如果支援獨立設定目錄或可攜模式，優先使用專案提供的隔離方式。
3. 保留原目錄：將已確認的資料目錄重新命名，備份名稱可使用 client-data.backup-20260819，不要刪除。
4. 使用預設設定啟動：允許用戶端建立新的使用者資料，先不要開啟 TUN、匯入訂閱或復原全部設定。
5. 逐層復原：先匯入已知有效的設定，檢查核心啟動，再復原必要規則與覆寫設定，最後啟用系統代理或 TUN。

如果空白資料目錄仍然閃退，舊設定很可能不是唯一原因；應回頭檢查系統當機日誌與版本相容條件。如果復原某一項後再次失敗，保留這次前後差異，比完整重裝更便於定位。需要還原舊目錄時，先退出程式，再保留本輪新目錄並恢復原名稱，避免直接混合兩套資料庫或快取。

復原後驗證與故障回報清單

視窗重新出現只是第一步。先觀察介面與核心是否穩定執行，再確認本機監聽連接埠，最後才測試代理流量。以下以監聽 127.0.0.1:7890 的 HTTP 混合連接埠為例，選擇有權限存取且目前網路可達的 HTTPS 位址進行驗證；範例位址的可達性仍受當地網路影響。

# macOS / Linux
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

# Windows：明確呼叫 curl.exe
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

這裡的 10 秒連線逾時與 20 秒總逾時是診斷上限，不是延遲成績。只看到 200 Connection established 不能認定目標請求已成功，還應檢查後續 TLS 與 HTTP 結果。如果仍使用前面的最小設定，流量會直連；驗證真實代理出口時，請恢復有效節點及對應規則，並在連線紀錄中確認命中的策略。

提交回報時保留可重現資訊

• 用戶端名稱、完整版本號、核心 -v 輸出，以及系統版本與架構。
• 安裝包類型、是否使用可攜模式或服務模式、TUN 是否開啟。
• 重現順序，例如「預設啟動正常 → 匯入設定正常 → 啟用覆寫後核心退出」。
• 故障發生時間、第一則具體錯誤、退出碼，以及去識別化後的相鄰日誌。
• 預設資料目錄測試、最小設定測試與連接埠檢查各自得到什麼結果。

若問題只在一次用戶端更新後出現，應帶著上述證據向相應專案回報。選擇其他用戶端前，可先閱讀用戶端選型指南確認平台與核心支援範圍；設定層面的問題可對照設定大全逐項檢查。能夠重現並隔離到某一步，比反覆重裝更容易形成可驗證的修復結論。