Clash 客戶端一開就閃退？排查日誌、還原設定與修復權限

先分辨視窗關閉、介面閃退與核心停止

「Clash 一開就閃退」可能是三種不同狀況：視窗縮到系統匣、圖形介面程序閃退，或介面仍在但核心啟動失敗。設定錯誤和連接埠衝突通常先影響核心，不一定會讓整個客戶端退出。先確認故障發生在哪一層，再決定要檢查設定或修復執行環境。

1. 檢查背景程序。Windows 按 Ctrl + Shift + Esc 開啟工作管理員；macOS 開啟「活動監視器」；Linux 使用 ps -ef。介面消失但客戶端和核心仍在執行時，先查看系統匣、選單列及多螢幕上的視窗位置。
2. 記錄重現條件。分辨是首次安裝後就失敗、升級後失敗、匯入訂閱後失敗，還是開啟 TUN 後失敗。記下作業系統版本、CPU 架構、客戶端版本及核心版本，不要只寫「最新版」。
3. 完整退出一次。從系統匣選單退出客戶端，確認相關程序已結束後再試一次。背景中的舊執行個體可能仍占用連接埠；反覆點兩下啟動只會增加干擾。

從日誌找線索：記下啟動時間與第一筆錯誤

客戶端日誌、核心日誌和系統閃退報告能回答不同問題。客戶端日誌著重介面初始化、核心路徑和服務連線；核心日誌著重 YAML、監聽連接埠和規則載入；系統報告則用來追查執行階段、動態函式庫及程序異常退出。

依作業系統查找啟動失敗紀錄

• Windows：按 Win + R，輸入 eventvwr.msc，前往「Windows 記錄」→「應用程式」，依故障時間查看「Application Error」等紀錄，記下故障應用程式、故障模組及例外代碼。客戶端資料可能位於 %APPDATA% 或 %LOCALAPPDATA%；可攜版也可能將資料寫入程式所在目錄，請以該客戶端文件和啟動日誌為準。
• macOS：開啟「主控台」查看閃退報告，也可檢查 ~/Library/Logs/DiagnosticReports/。記下程序名稱、例外類型和終止原因；不要把其他應用程式同期產生的報告當成代理客戶端日誌。
• Linux：從終端機啟動實際安裝的執行檔，查看標準錯誤輸出。若系統使用 systemd，可查看 journalctl --user -b --since "10 minutes ago"；若已啟用閃退收集，再用 coredumpctl list 查找對應程序。不同發行版不一定使用相同的收集機制。

依錯誤關鍵字決定下一步

日誌最後的「核心已停止」通常只是結果。往前找出這次啟動最早出現的具體錯誤，並保留前後約 30 行。分享前請隱藏訂閱網址、驗證資訊、控制介面金鑰及個人目錄名稱；代理節點位址也可能是敏感資訊。

還原設定：驗證實際載入的 YAML

訂閱更新後馬上失敗，優先檢查設定變更。訂閱原始檔不一定是核心實際讀取的最終檔案：客戶端可能還會套用覆寫、指令碼、規則片段或 TUN 設定。只驗證下載的訂閱，無法排除合併過程產生的錯誤。

1. 完整退出客戶端，備份目前的訂閱、覆寫檔案及客戶端設定，不要直接刪除資料目錄。
2. 還原最近一次能正常啟動的設定，並暫時停用新加入的覆寫或指令碼。若無法進入介面，請先備份，再依客戶端文件還原對應設定檔；不要臆測內部資料庫的結構。
3. 使用客戶端實際內附的核心測試最終設定。舊版 Clash 和 mihomo 支援的通訊協定與欄位不同，不能用另一個核心的測試結果代替。
4. 成功還原啟動後，逐項啟用訂閱更新、規則集、自訂 DNS 和 TUN，找出再次觸發故障的變更。

以 mihomo 為例，在終端機切換到核心所在目錄，將待檢查的設定副本存成該目錄下的 config.yaml，再執行對應命令。若設定引用相對路徑，請透過 -d 指定正確的資料目錄，並保持相關檔案的位置一致。

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

# macOS / Linux
./mihomo -t -f ./config.yaml

-t 用來測試設定，不代表所有遠端規則集、節點連線狀況和執行時權限都已驗證。若日誌指出特定行號，也要檢查前一行：漏寫冒號、使用 Tab 縮排或清單層級錯誤，都可能讓解析器到下一行才回報錯誤。

最小設定僅用於隔離問題

以下設定用來確認核心能否正常啟動，不包含代理節點，所有符合條件的流量都會直連。請另存為獨立測試檔，檢查完成後再還原原設定；不要把它當成可用的代理訂閱。

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

rules:
  - MATCH,DIRECT

若最小設定能啟動、原設定卻失敗，優先檢查節點通訊協定、策略組引用、規則集路徑及覆寫結果。若最小設定也無法啟動，請繼續檢查連接埠、核心檔案和系統環境。範例中的 17890 仍須確認未被占用。

連接埠衝突：確認監聽程序及占用來源

常見設定會使用 7890 作為混合代理連接埠、9090 作為控制介面連接埠，但這些並非所有客戶端的固定值。請以日誌和最終設定為準；HTTP、SOCKS、DNS 的監聽連接埠也可能各自發生衝突。

在 Windows 查詢監聽 PID

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

Get-Process -Id 4321

第二個命令中的 4321 是範例 PID，請替換成第一個命令回傳的值。若查到舊客戶端，優先從系統匣選單退出；若是其他服務，先確認用途，不要直接結束不熟悉的系統程序。若沒有權限讀取完整資訊，再視需要使用系統管理員終端機。

在 macOS 與 Linux 查詢連接埠

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

# Linux
ss -lntp

這些命令用於查詢 TCP 監聽。若錯誤與 DNS 的 UDP 監聽有關，還需使用 lsof -nP -iUDP:1053 或 Linux 的 ss -lnup，並將 1053 換成實際連接埠。修改連接埠後，也要同步更新系統代理、瀏覽器擴充功能及命令列代理環境變數，否則可能出現「客戶端啟動成功，但應用程式無法連網」的情況。

核心檔案與 TUN 權限：依失敗對象修復

升級中斷、檔案遭安全軟體隔離或安裝目錄無法寫入，都可能讓客戶端找不到核心。先從日誌確認實際核心路徑，再檢查檔案是否存在。不要將任意下載的二進位檔改名後替換，客戶端可能仰賴特定啟動參數、控制介面行為或配套資源。

• Windows：前往「Windows 安全性」→「病毒與威脅防護」→「保護歷程記錄」，查看是否有相關紀錄。確認來源及警示內容後再決定如何處理，不要關閉整體防護。安裝版優先使用原安裝程式修復；可攜版可解壓縮至目前使用者有寫入權限的新目錄測試。
• macOS：確認安裝檔適用於 Apple 晶片或 Intel 架構。若系統明確提示應用程式遭封鎖，確認來源後，再查看「系統設定」→「隱私權與安全性」中的相關選項；不要批次移除整個下載目錄的安全屬性。
• Linux：使用 uname -m 查看電腦架構，使用 file ./mihomo 查看核心檔案類型。檔案存在卻仍無法執行時，也要檢查動態載入器、掛載選項及架構，不要只歸因於「權限不足」。

在 Linux 上，只有確認目標檔案可信且確實缺少執行權限時，才對該檔案執行 chmod u+x ./mihomo。不要對整個使用者目錄遞迴設定過寬權限，也不要長期以 root 執行圖形介面來繞過資料目錄的權限錯誤。

開啟 TUN 後失敗的隔離方式

先關閉 TUN，只啟動核心和本機代理連接埠。若一般代理模式可正常運作，開啟 TUN 後卻出現建立裝置、路由或權限錯誤，問題範圍就集中在虛擬網卡與特權服務。Windows 客戶端通常透過系統管理員權限或服務模式完成相關操作；macOS 可能需要安裝輔助程式；Linux 常涉及 /dev/net/tun 和網路管理權限。具體安裝方式會隨客戶端版本而異，請使用該版本提供的服務安裝流程。

測試時也先暫停其他 VPN 或另一套 TUN 客戶端，避免多套工具同時修改預設路由。修復後先驗證一般代理，再啟用 TUN；不要同時修改 DNS、路由和訂閱，否則很難確認是哪項操作生效。

介面執行環境：WebView2、Electron 與系統元件

核心可以獨立啟動，但視窗仍然一片空白或立即消失時，再檢查圖形介面的執行環境。不同客戶端採用的技術各異：部分 Windows 客戶端依賴 WebView2，另一些使用 Electron 或 Flutter。看到「Clash」就一律重裝 WebView2，可能與實際故障無關。

1. 確認客戶端相依元件。查看該版本的安裝說明與系統需求。明確依賴 WebView2 的 Windows 客戶端，可在「設定」→「應用程式」→「已安裝的應用程式」搜尋 Microsoft Edge WebView2 Runtime；不同系統版本的清單位置可能有所差異。
2. 依官方流程修復。使用 Microsoft 官方提供的 WebView2 Runtime 安裝程式進行修復或重新安裝，再重新啟動客戶端。不要從不明網站下載 DLL 並放進程式目錄。
3. 確認故障模組。Electron 或 Flutter 客戶端應依據日誌排查執行階段、圖形驅動程式及應用程式資源。只有客戶端文件明確支援時，才嘗試停用硬體加速；不要照搬其他客戶端的啟動參數。

Linux 的 WebKitGTK、圖形工作階段及動態函式庫相依項目，會因安裝套件類型而異。優先從終端機取得明確缺少的函式庫名稱，再使用發行版的套件管理器處理；不要混用其他發行版的函式庫。macOS 則先確認系統版本符合目前安裝檔的需求，再考慮重新安裝客戶端。

隔離資料目錄：保留可還原的舊狀態

設定驗證、連接埠檢查和執行環境修復都無效時，再測試全新的使用者資料。解除安裝後重新安裝不一定會清除使用者目錄，因此「重裝後仍閃退」不能直接證明安裝檔有問題。

1. 退出所有相關程序。若背景服務仍在寫入，請先透過客戶端支援的方式停止，避免備份期間檔案變動。
2. 確認實際目錄。依據日誌、文件或客戶端提供的目錄入口找出資料位置，不要混淆安裝目錄、系統快取和使用者設定。
3. 複製並重新命名。先備份整個目錄，再將原目錄改名為包含日期的名稱，例如 client-data-backup-20260929。不要立刻永久刪除，也不要公開上傳整個目錄。
4. 以空白狀態啟動。不匯入訂閱、不啟用 TUN，先確認介面和核心都正常，再逐項還原訂閱、自訂規則、覆寫及偏好設定。

如果空白狀態正常，但還原某項後再次失敗，請保留該項的最小重現副本。不要直接覆蓋整個目錄，否則損壞的狀態檔也會一併還原。若空白狀態仍會失敗，而相同核心可獨立正常執行，應優先提交介面層的閃退資訊，而不是繼續修改代理規則。

修復驗收與故障回報資訊

視窗能開啟只是第一步。修復後應確認核心持續執行、監聽連接埠正確、訂閱能正常載入，且啟用所需功能後不會再次退出。測試系統代理與 TUN 時請分開進行，並檢查原有系統代理設定是否已恢復至預期狀態。

• 啟動驗收：連續正常啟動並退出兩次，確認退出後沒有殘留程序占用相同連接埠。
• 設定驗收：手動更新一次訂閱，查看最終設定的測試結果及規則集載入狀況；若失敗，請保留舊設定，不要自動覆蓋唯一可用的副本。
• 模式驗收：先驗證本機代理，再測試系統代理，最後視需要啟用 TUN，逐項查看日誌。
• 回報資料：提供作業系統版本、架構、客戶端與核心版本、重現步驟、第一筆錯誤及已遮蔽敏感資訊的日誌，並註明最小設定和全新資料目錄是否能啟動。

回報問題時，清楚寫出「升級後啟動兩秒就退出，最小設定正常，還原某段覆寫後可重現」，比只附一張錯誤視窗截圖更容易找出原因。排查結束後，將暫時調高的日誌等級還原為日常設定，妥善保存可用的設定備份，並清除含敏感資訊的暫存診斷檔。