Clash 客戶端一開就閃退？查看日誌、排除連接埠衝突並還原設定

先分清楚：是視窗關閉，還是核心啟動失敗

先查看系統匣或選單列，再檢查處理程序清單。關閉視窗後圖示仍留在系統匣，可能只是客戶端設定為「關閉時縮到系統匣」，不一定是閃退。若視窗仍能開啟，但顯示連線失敗或代理無法使用，問題可能出在核心未啟動。核心負責讀取設定、比對規則並轉送連線，圖形介面則是操作入口。

記下故障發生前最後執行的操作。更新訂閱後出錯，先檢查設定；啟用 TUN 後出錯，先檢查權限與虛擬網卡；升級客戶端後連視窗都打不開，先查看應用程式崩潰報告及安裝檔架構。不要同時更新軟體、更換訂閱又修改連接埠，否則無法判斷是哪個變更造成影響。

查看日誌：保留首次失敗前後的資訊

介面能開啟時，先查看核心日誌

開啟客戶端的「日誌」頁面，或在「設定」中尋找「開啟設定資料夾」、「開啟日誌資料夾」等選項。各客戶端的選單名稱不盡相同，不要直接套用其他客戶端的資料夾路徑。優先查看本次啟動時間附近的記錄，保留錯誤訊息前後約 20 行；末尾反覆出現的「重新連線」通常只是結果。

分辨應用程式日誌與核心日誌。應用程式日誌記錄視窗、更新與服務呼叫；核心日誌記錄設定解析、連接埠監聽、規則載入及連線處理。如果介面顯示「無法連線至控制連接埠」，也要往前查看核心是否已因設定錯誤而結束，別直接認定是控制連接埠遭占用。

視窗無法開啟時，查看系統記錄

• Windows：按下 Win + R，輸入 eventvwr.msc，前往「Windows 記錄」→「應用程式」，依發生時間尋找應用程式錯誤。也可以執行 perfmon /rel 開啟可靠性監視器，查看該程式的失敗記錄。
• macOS：開啟「主控台」App，查看「崩潰報告」，依處理程序名稱和時間尋找對應報告。留意異常類型、終止原因和出錯執行緒，不要只截取報告標題。
• Linux：從終端機啟動實際的客戶端可執行檔，查看標準錯誤輸出；若由使用者層級服務啟動，使用 journalctl --user -b 查看本次啟動的使用者服務日誌。

先用關鍵字縮小範圍。yaml、unmarshal、parse 通常指向設定解析問題；address already in use 表示位址或連接埠衝突；permission denied、operation not permitted 則指向權限問題。日誌中的 error 不一定代表程式崩潰，例如單一規則來源下載失敗時，還要確認後續是否仍能繼續啟動。

檢查設定：先驗證 YAML，再確認核心支援

先檢查最近修改的幾行。YAML 以縮排表示層級，請使用空格，不要混用 Tab。常見問題包括冒號後漏了空格、列表項目漏寫短橫線、引號未成對，以及把 rules 寫在 dns 底下。錯誤行可能只是解析器最後發現問題的位置，也要一併檢查前一段設定。

確認目前執行的核心。Clash、Clash Meta 與 mihomo 支援的設定項目並不完全相同，圖形介面顯示的名稱也不一定等於核心名稱。查看「關於」頁面或啟動日誌，記下客戶端版本與核心版本；不要只憑安裝檔名稱判斷是否支援特定欄位。

使用同一個核心測試設定副本

將待檢查檔案複製為 recovery.yaml，並在副本上操作。以下命令適用於 mihomo：先用 -v 查看版本，再用 -t 測試設定。請使用客戶端實際呼叫的核心，不要隨意下載其他版本代替測試。

# Windows PowerShell：在核心與測試檔案所在資料夾執行
.\mihomo.exe -v
.\mihomo.exe -t -d . -f .\recovery.yaml

# macOS / Linux：在對應資料夾執行
./mihomo -v
./mihomo -t -d . -f ./recovery.yaml

-f 用來指定設定檔，-d 用來指定工作目錄。這裡的 . 代表目前目錄；若原設定引用相對路徑的規則檔，請一併將所需檔案複製到測試資料夾。缺少本機資源也可能導致測試失敗，不能一概視為 YAML 語法錯誤。

使用最精簡設定，隔離訂閱與覆寫問題

如果無法確認是哪一段出錯，可以先在副本中使用以下 mihomo 設定。此設定會關閉 TUN 和內建 DNS，只提供本機混合代理連接埠，並直接連線至目標位址。它僅用於確認基本啟動是否正常，不提供遠端代理功能，也不能取代完整訂閱設定。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

tun:
  enable: false

dns:
  enable: false

rules:
  - MATCH,DIRECT

若最精簡設定能啟動，請依序恢復「訂閱主體 → 自訂規則 → DNS → TUN」，每恢復一項就重新啟動一次。若只有在自動更新訂閱後才再次出錯，請檢查訂閱格式及客戶端的覆寫邏輯。許多客戶端會重新產生執行設定，直接編輯產生的檔案可能在下次啟動時失效。

排查連接埠占用：先找出處理程序，再決定是否更換連接埠

以日誌中的連接埠為準。7890 常用作 HTTP 與 SOCKS 混合代理連接埠，9090 則常用於控制介面，但這些值都可以修改。也要分辨監聽失敗與連線失敗：若錯誤出現在 bind 附近，才較可能是本機監聽問題；連線至遠端節點逾時並非本機連接埠衝突。

Windows：查出監聽處理程序的 PID

開啟 PowerShell，執行以下命令。PID 是處理程序識別碼，可用來確認監聽連接埠的是哪個程式。如果命令沒有輸出，表示查詢當下沒有發現這些 TCP 監聽項目，不代表程式啟動時沒有發生衝突。

Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

# 列出監聽處理程序的名稱
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty OwningProcess -Unique |
  ForEach-Object { Get-Process -Id $_ -ErrorAction SilentlyContinue }

macOS / Linux：查看 TCP 監聽程序

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

先正常結束舊客戶端，再檢查是否仍有核心或背景服務在執行。不要只因為連接埠遭占用就強制結束不熟悉的處理程序，更不要停止系統服務。若決定將混合代理連接埠改為 7895，先確認新連接埠未被占用，再同步修改瀏覽器手動代理、終端機環境變數及其他呼叫端設定。

控制連接埠要另外處理。修改 external-controller 後，圖形介面也必須連線至新的位址；部分客戶端會自行管理此欄位，手動覆寫可能導致介面無法連線。若日誌指向 DNS 的 53 連接埠，則應另外檢查 UDP/TCP 監聽與系統解析服務；前述 TCP 查詢無法涵蓋 DNS 衝突。

檢查權限與服務模式：先關閉 TUN 測試

先關閉 TUN，再啟動一般代理。TUN 透過虛擬網卡接管流量，通常會涉及系統路由、網卡及較高權限。關閉後若能啟動，表示問題範圍已縮小至虛擬網卡、權限、服務或相關設定，不必再反覆更換訂閱。

1. 確認背景服務狀態。在客戶端設定中檢查「服務模式」或相應的服務管理項目。Windows 可執行 services.msc，核對客戶端顯示的確切服務名稱、狀態及可執行檔路徑，不要根據相似名稱猜測。
2. 排除升級後路徑變更的影響。可攜版移動了資料夾，或舊服務仍指向已刪除的檔案，都可能導致服務無法啟動。先結束客戶端，再使用該客戶端內建的服務修復功能，或透過重新安裝服務的選項處理。
3. 檢查設定資料夾的寫入權限。嘗試在備份資料夾中建立一般文字檔。若應用程式設定資料夾位於唯讀位置、擁有者是其他使用者，或遭安全軟體封鎖，請依據日誌修正相應的存取權限。
4. 最後才重新啟用 TUN。確認一般代理運作穩定後，再單獨啟用 TUN 並檢查日誌。避免同時執行多個會接管路由的代理或 VPN，以免虛擬網卡和路由規則互相干擾。

不要把「永遠以系統管理員身分執行」當成通用解法。暫時提高權限有助於判斷是否為權限問題，但長期處理應依照客戶端提供的服務安裝流程。macOS 背景輔助元件與 Linux 服務權限也應依各客戶端說明設定，不建議讓整個程式資料夾都能任意寫入。

安全還原：回到最後可用的設定，不要直接清空資料夾

先保留故障現場，再還原至最後可用狀態。直接刪除整個設定資料夾，可能連訂閱來源、規則覆寫和故障證據一併遺失。即使決定重新初始化，也應先備份並重新命名資料夾，而非立即刪除。

1. 完全結束程式。關閉視窗後，檢查系統匣、選單列及相關處理程序；若背景服務仍在管理核心，請先透過客戶端正常停止服務或核心。
2. 複製備份。將實際設定資料夾複製為附有日期的副本，例如 clash-backup-2026-09-30，並另外保存故障日誌。
3. 只還原與故障相關的項目。修改規則後出錯，先還原覆寫規則；更新訂閱後出錯，先切回可用設定。不要一開始就替換所有應用程式設定。
4. 暫停自動更新。若客戶端支援，請暫時停用該訂閱的定期更新，避免剛還原的內容再次遭覆寫；修復完成後再恢復更新。
5. 確認三項狀態。確認介面持續運作、日誌不再反覆顯示重新啟動，且預期的連接埠已成功監聽。接著使用完整訂閱設定，確認代理連線正常。

若懷疑應用程式設定本身已損毀，可先備份，再重新命名設定資料夾，讓客戶端建立新資料夾。不過，各客戶端的資料目錄位置不盡相同，有些可攜版會使用程式所在資料夾，有些則使用使用者資料目錄；請先確認日誌記錄的實際路徑。重新初始化後不要立刻匯入整份舊設定，以免故障再次發生。

若問題在升級後立即出現，請記下新舊客戶端與核心版本，再考慮透過專案正式發布管道退回已知可用版本。新版本寫入的資料結構未必與舊版相容，因此請先分別保存升級前後的備份，不要讓舊版反覆改寫唯一的資料目錄。

仍然閃退？整理一份可重現的排查紀錄

整理好資訊後再回報問題。只說「一打開就消失」，無法分辨是圖形介面崩潰、核心結束，還是背景服務失敗。若涉及系統層級錯誤，可接著參閱疑難排解；不確定設定的匯入位置時，請查看使用教學。

• 環境：作業系統版本、CPU 架構、客戶端完整版本、核心完整版本，以及安裝版或可攜版。
• 觸發步驟：從啟動到結束需要多久，以及是否只在匯入特定訂閱、啟用 TUN 或切換服務模式後發生。
• 測試結果：最精簡設定能否啟動、設定測試是否通過，以及 7890 或實際使用的連接埠由哪個處理程序監聽。
• 日誌片段：本次失敗的時間、第一則關鍵錯誤及其前後文；若視窗崩潰，另附系統報告中的故障模組或異常類型。

依照「日誌 → 設定 → 連接埠 → 權限 → 還原」的順序逐項檢查，每次只變更一個條件。這樣既能縮小閃退原因，也能保留明確的復原方式，避免為了解決啟動問題又造成新的設定差異。