先釐清：是視窗關閉、核心退出，還是整個用戶端崩潰

按兩下圖示後看不到視窗，不一定代表 Clash 閃退。桌面用戶端通常由圖形介面、代理核心和選用的背景服務組成。視窗可能縮到系統匣；介面也可能正常啟動，但 mihomo 核心因設定錯誤而退出。先找出出問題的部分，才能對症處理，避免白忙一場。

  1. 檢查系統匣或選單列。Windows 展開工作列右側的隱藏圖示；macOS 查看螢幕頂端的選單列。如果看到圖示，先嘗試「顯示主畫面」，不要連續啟動多個執行個體。
  2. 檢查處理程序。Windows 開啟「工作管理員」→「詳細資料」；macOS 開啟「活動監視器」；Linux 使用系統監視器。確認用戶端處理程序及 mihomo 等核心處理程序是否仍在執行。
  3. 記下問題發生的時機。剛升級後無法開啟、更新訂閱後退出、啟用 TUN 後退出，分別可能指向程式環境、設定或權限問題。
  4. 結束重複執行的執行個體後再試一次。先從系統匣結束程式，再確認處理程序已停止。背景服務可能仍在執行，不能只憑關閉視窗就認定程式已完全退出。

尋找啟動日誌：各平台的查看位置

如果還能開啟介面，優先在「設定」中尋找「開啟日誌資料夾」、「開啟設定資料夾」或「應用程式資料夾」等入口。介面日誌常會記錄核心輸出，但不一定包含介面本身的崩潰資訊；完全無法開啟時，也要查看系統的崩潰記錄。

平台優先檢查位置注意事項
Windows %APPDATA%、%LOCALAPPDATA% 中的用戶端資料夾；「事件檢視器」→「Windows 記錄」→「應用程式」 傳統版 Clash for Windows 通常使用 %USERPROFILE%\.config\clash；可攜版可能會將資料放在程式所在資料夾。
macOS ~/Library/Logs/DiagnosticReports/；~/Library/Application Support/ 中的用戶端資料夾 透過「Finder」→「前往」→「前往檔案夾」輸入路徑。系統崩潰報告通常是 .ips 檔案。
Linux ~/.config/、~/.local/share/、~/.local/state/ 中的應用程式資料夾；終端機輸出與 systemd 日誌 Flatpak 資料通常位於 ~/.var/app/ 下對應的應用程式資料夾，與一般安裝套件不同。
Android 從應用程式內匯出日誌；ADB 的 logcat 與 crash 緩衝區 一般檔案管理員通常無法直接讀取應用程式的私人資料夾。請先匯出資料，再考慮清除。

Windows：查看錯誤模組，不要只看「應用程式錯誤」

按 Win + R，輸入 eventvwr.msc，再依問題發生時間篩選應用程式事件。事件 ID 1000 常見於應用程式崩潰，1001 可能包含 Windows 錯誤報告資訊；這些只是線索，不能直接當作原因結論。記下「錯誤應用程式名稱」、「錯誤模組名稱」及「例外狀況代碼」，再與用戶端日誌比對。

Linux 與 Android：保留可重現的輸出

Linux 可從終端機執行用戶端的實際執行檔；如果使用使用者層級的 systemd 服務，可先查看最近 10 分鐘的日誌。以下 Android 指令需要先安裝 ADB、開啟 USB 偵錯並授權電腦，建議重現問題後立即執行：

# Linux：查看使用者層級的工作階段日誌
journalctl --user --since "10 minutes ago" --no-pager

# Android：將崩潰緩衝區匯出至電腦目前資料夾
adb logcat -b crash -d > clash-crash.txt

分享日誌前，請遮蔽訂閱網址中的權杖、節點密碼、UUID、控制介面金鑰，以及不想公開的存取網域。只貼出錯誤前後約 30 行，通常比上傳整個設定資料夾更容易找出問題，也能減少資訊外洩。

原因一：YAML 語法錯誤，或設定與核心不相容

如果問題是在編輯設定、更新訂閱或更換核心後開始，先找 yaml:、unmarshal、proxy group、not found 等訊息。YAML 使用空格縮排，不能用 Tab 取代；冒號後少了空格、清單縮排錯誤，都會造成解析失敗。

  • 語法錯誤：日誌出現 line 18 時，檢查第 18 行及前面幾行。報錯位置可能只是解析器終於無法繼續處理的地方。
  • 引用錯誤：代理群組引用了不存在的節點名稱，或規則引用了未定義的代理群組、規則集合，這類問題屬於設定語意錯誤，單純調整縮排無法修復。
  • 核心不相容：Clash、Clash Premium 與 Clash Meta（現稱 mihomo）支援的功能範圍不同。特定通訊協定或設定欄位是否可用，取決於實際啟動的核心及其版本，不只看介面上的品牌名稱。
  • 下載內容有誤：訂閱網址過期後，可能會傳回登入頁面或錯誤文字。檢查檔案開頭是否變成 HTML，不要把伺服器的錯誤頁面當成 YAML 匯入。

使用相同核心測試設定

先複製要檢查的設定，避免直接修改由訂閱產生的檔案。使用 mihomo 的用戶端可呼叫實際核心進行測試；如果設定引用相對路徑的檔案，也應指定原本的工作目錄。以下是 Windows PowerShell 範例，執行前須先切換至實際核心所在資料夾，並準備好相關檔案：

.\mihomo.exe -v
.\mihomo.exe -t -d "C:\Clash-Debug" -f "C:\Clash-Debug\config.yaml"

-v 用來確認版本，-t 用來檢查設定。先將設定及所需的本機規則檔案放入測試資料夾，再執行指令；缺少資源或遠端下載失敗，也可能導致測試失敗。不要把所有問題都歸咎於 YAML 縮排。測試通過只代表該次檢查成功，並不保證 TUN 權限、連接埠繫結及網路存取都正常。

原因二：7890 或控制介面連接埠已被占用

日誌出現 bind: address already in use，或 Windows 顯示「通常每個通訊端位址只允許使用一次」時，請檢查監聽連接埠。混合連接埠常見為 7890，控制介面常見為 9090，但兩者都能修改，請以目前設定為準。連接埠衝突通常會導致核心啟動失敗，不一定會讓整個圖形介面退出。

# Windows PowerShell：依實際連接埠篩選監聽項目
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 |
  Select-Object LocalAddress,LocalPort,OwningProcess

# macOS：查看 7890 的 TCP 監聽處理程序
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：列出 TCP 監聽連接埠及處理程序
ss -ltnp

Windows 可使用 Get-Process -Id 進程編號 查詢上一步顯示的 PID。常見的占用者包括另一個代理用戶端、舊的核心處理程序或仍在執行的服務。先確認處理程序身分，再透過對應程式正常退出；不要看到連接埠被占用就直接強制結束系統處理程序。

  1. 關閉其他代理用戶端及不再需要的背景服務，再重新啟動一次。
  2. 如果確實需要同時執行兩個程式，請將其中一個的混合連接埠改為未被占用的連接埠，例如 7897，然後再次確認監聽狀態。
  3. 手動設定代理的瀏覽器、終端機及區域網路裝置也要同步修改。只改核心連接埠、不改應用程式的代理位址，就會出現「用戶端已啟動，但應用程式無法連網」的情況。

permission denied 或「嘗試以存取權限不允許的方式存取通訊端」不等於連接埠已被占用。原因也可能是系統保留連接埠、安全性原則或繫結權限，請繼續查看完整錯誤訊息。

原因三：核心檔案缺漏、架構不符或安裝不完整

如果出現 no such file or directory、failed to spawn、exec format error，請先檢查程式是否安裝完整。有些發行版本會將介面與核心分開放置，只複製主程式可能會漏掉套件隨附的資源和輔助程式。

  • 確認架構：Windows 在「設定」→「系統」→「系統資訊」查看系統類型；macOS 在「關於這台 Mac」查看晶片；Linux 執行 uname -m。x86_64 與 aarch64 對應不同版本，不能任意互換。
  • 檢查安裝方式：壓縮檔請完整解壓縮至固定資料夾後再啟動。macOS 請先將應用程式複製到「應用程式」資料夾再執行，不要長期直接從磁碟映像檔啟動。
  • 檢查安全軟體記錄：Windows 開啟「Windows 安全性」→「病毒與威脅防護」→「保護歷程記錄」。先確認檔案來源和偵測詳細資料，不要為了啟動程式而直接關閉整套防護。
  • 重新安裝程式檔案：從專案正式發布管道取得與作業系統相符的安裝套件。先保留使用者資料，不要把「重新安裝程式」和「刪除設定」混在同一個步驟處理。

Linux 出現「檔案不存在」時，即使目標檔案確實存在，也可能是動態載入器或相依程式庫缺漏。可信來源的執行檔可使用 file 查看架構，再根據終端機的相依性錯誤處理。不要只因檔案大小正常，就認定程式完整且可執行。

原因四與五：TUN 權限、服務異常及執行階段缺漏

只有啟用 TUN 後才退出？先改用一般代理測試

TUN 需要建立虛擬網卡及設定路由，部分設定還會接管 DNS，通常需要較高權限。如果關閉 TUN 後能正常啟動，請先檢查用戶端的「服務模式」或特權輔助程式，不要反覆更換訂閱。

  1. 先關閉其他正在接管網路的 VPN 或代理工具，只保留一個用戶端進行測試。
  2. 如果還能開啟介面，請關閉 TUN 後重新啟動，確認一般代理是否可用。
  3. 使用目前用戶端提供的安裝或修復入口處理服務，並確認服務對應的是目前的安裝資料夾。移動可攜版資料夾後，舊服務可能仍指向原本的路徑。
  4. macOS 請檢查特權輔助程式的授權；Linux 請查看服務日誌中的權限錯誤。不要將整個設定資料夾設為任何人都能寫入，也不要長期以 root 執行圖形介面來掩蓋問題。

Android 的 VPN 授權遭拒，或 VPN 連線已被其他應用程式占用時，通常會表現為連線失敗，而非應用程式處理程序崩潰。只有系統崩潰記錄明確指出應用程式異常時，才繼續依閃退問題排查。

視窗白屏或一閃即逝？檢查介面執行環境

不同介面技術的相依項目各不相同。使用 Tauri 的 Windows 用戶端通常需要 Microsoft Edge WebView2；以 Electron 為基礎的用戶端通常會隨套件附帶自己的 Chromium 環境，因此不能把所有白屏問題都歸咎於 WebView2。請依照該用戶端的發布說明確認執行需求，再安裝或修復 Microsoft 提供的對應元件。

如果出現找不到 VCRUNTIME140.dll 或 MSVCP140.dll 的提示，請依軟體需求安裝 Microsoft Visual C++ Redistributable，並選擇相符的程式架構。不要從 DLL 下載網站另外下載檔案。Linux 若回報缺少共享程式庫，請依發行版及專案的相依性說明安裝對應套件；同樣不要將來源不明的程式庫複製到系統資料夾。

安全重設設定：先改名隔離，比直接刪除更妥當

如果設定檢查仍找不到原因，或用戶端升級後讀取舊的介面狀態就崩潰，可用全新的使用者資料測試。不過這可能影響訂閱、規則覆寫、代理群組選擇、快速鍵、服務及 TUN 設定，因此應在檢查日誌後再進行。

  1. 先匯出或複製資料。保存訂閱來源、本機設定、規則覆寫、指令碼及用戶端設定。備份可能包含憑證，請存放在安全的位置。
  2. 完全退出程式。關閉系統匣中的程式，並確認相關核心已停止；若需處理服務，請使用用戶端提供的服務管理入口。
  3. 隔離實際使用者資料資料夾。確認該資料夾是目前用戶端正在使用的資料夾後，將它重新命名，例如加上 .backup-20261021。不要重新命名整個 AppData 或 .config 資料夾。
  4. 以預設狀態啟動。如果能正常開啟，先不要啟用 TUN，只匯入一份確認可用的設定，測試啟動與退出是否正常。
  5. 逐項還原。依序還原訂閱、規則覆寫、介面設定及 TUN，每還原一項就重新啟動一次。不要將舊資料夾全部複製回去，否則可能連問題也一起還原。

使用全新資料仍然崩潰，表示排查方向應轉向程式版本、執行環境或系統相容性。此時反覆重設設定通常沒有幫助；可保留備份，依專案發布說明測試其他相容版本，並避免讓舊版直接寫入新版的資料資料夾。

回報問題前的檢查清單

尋求協助時，請將「打不開」改寫成可重現的步驟。提供以下資訊，維護者就能先判斷問題出在介面、核心還是系統環境，也能減少來回詢問。

  • 用戶端名稱與完整版本號、核心名稱與版本、作業系統版本及 CPU 架構。
  • 安裝套件類型、安裝資料夾是否曾移動，以及是否從舊版升級。
  • 重現步驟，例如「啟動後 2 秒退出」或「開啟 TUN 後立即退出」；不要把觀察到的現象寫成尚未確認的原因。
  • 故障時間、相關日誌、系統崩潰模組，以及設定測試的完整錯誤訊息。
  • 關閉 TUN、停止其他用戶端、改用全新資料資料夾後，結果分別如何。

修復後再完整檢查一次：主畫面能重複開啟；代理核心持續執行；本機連接埠確實處於監聽狀態；手動設定代理的應用程式使用正確連接埠；正常退出後不會留下系統代理設定。若先前啟用了 TUN，請另外測試其啟動與關閉。這樣才能區分「視窗終於出現」和「代理連線已恢復正常」。