Clash 客戶端打不開怎麼辦：啟動崩潰與閃退排查處理步驟

先判斷故障發生在啟動的哪個步驟

Clash 圖形客戶端啟動時並非只執行一個程式。常見流程是：桌面外殼先載入介面，接著讀取應用程式設定與訂閱設定，再啟動 Clash Meta（mihomo）核心，最後繫結代理伺服器連接埠、控制連接埠，以及選用的 TUN 虛擬網卡。任何一步失敗，都可能呈現為「點擊後沒有反應」、「視窗出現後立即消失」，或「介面能開啟但核心始終啟動失敗」。

排查前先完整退出舊程序。Windows 可在「工作管理員」→「詳細資料」中結束客戶端程序與 mihomo.exe；macOS 可在「活動監視器」中搜尋客戶端名稱與 mihomo；Linux 可使用 ps 查看殘留程序。系統匣圖示消失不代表背景程序一定已結束，連續點擊啟動反而可能建立第二個執行個體並造成新的連接埠衝突。

先保留有助於定位問題的檔案

準備重設前，應複製訂閱設定、手寫 YAML、規則集與記錄。客戶端仍能進入介面時，可依序查看「設定」→「設定檔目錄」以及「設定」→「記錄」；介面無法開啟時，可從系統的使用者資料目錄尋找。Windows 常見位置為 %APPDATA% 或 %LOCALAPPDATA%，macOS 常見位置為 ~/Library/Application Support/，Linux 常見位置為 ~/.config/。不同客戶端使用各自的目錄名稱，不應將整個目錄直接覆蓋至另一款客戶端。

第一優先級：排除連接埠占用與重複程序

Clash 設定經常使用 7890 作為 HTTP 或 mixed 代理連接埠，7891 作為 SOCKS 連接埠，9090 作為外部控制連接埠。這些只是常見數值，並非固定要求。舊版 Clash、另一款代理客戶端、開發伺服器或尚未退出的 mihomo 都可能占用同一連接埠。核心通常會在記錄中顯示 address already in use、bind 或「只能使用一次通訊端位址」等訊息。

Windows 檢查方法

開啟 PowerShell 或命令提示字元，分別檢查三個常見連接埠。最後一欄是程序 PID，再使用 tasklist 查詢具體程式：

netstat -ano | findstr :7890
netstat -ano | findstr :7891
netstat -ano | findstr :9090
tasklist /FI "PID eq 4321"

確認 PID 對應的是已不再使用的舊執行個體後，可先從該程式本身的退出選單關閉；無法正常退出時，再在「工作管理員」→「詳細資料」中結束工作。不要看到連接埠正在監聽就直接終止系統程序，因為該連接埠可能已由其他必要服務主動設定。

macOS 與 Linux 檢查方法

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

若連接埠確實屬於另一款代理工具，可以關閉另一個工具，也可以修改 Clash 目前的設定。例如將 mixed 連接埠從 7890 暫時改為 17890，控制連接埠從 9090 改為 19090。修改後還要同步檢查系統代理設定、瀏覽器擴充功能與區域網路裝置，確保它們連線至新的連接埠。

mixed-port: 17890
external-controller: 127.0.0.1:19090
allow-lan: false
mode: rule

第二優先級：檢查 YAML 設定與訂閱內容

如果故障緊接在更新訂閱、編輯規則或切換設定後發生，設定解析錯誤的可能性很高。YAML 依靠縮排表達階層，Tab 字元、遺漏冒號、清單前缺少短橫線，以及字串中的特殊字元未加引號，都會讓核心在載入階段停止。記錄通常會指出 yaml、unmarshal、mapping values 或某個行號。

使用 mihomo 直接驗證設定

如果已找到 mihomo 可執行檔，可以在終端機中執行設定測試。-t 代表測試設定，-f 後接檔案路徑。路徑包含空格時需要使用引號：

mihomo -t -f "C:\Users\Public\Documents\clash\config.yaml"

macOS 或 Linux 的寫法相同，只需替換路徑：

./mihomo -t -f "$HOME/.config/mihomo/config.yaml"

測試通過通常會回傳設定初始化完成的訊息；測試失敗則會顯示欄位或行列位置。先修正最早出現的錯誤，因為後續錯誤可能只是第一個縮排問題造成的連鎖結果。

幾種容易導致啟動失敗的寫法

• 混用縮排：同一層級應保持相同的空格數，將編輯器設定為插入空格，不要使用 Tab。
• 引用不存在的策略組：rules 指向的策略名稱必須能在 proxy-groups 中找到，名稱包含空格時應保持完全一致。
• 節點名稱重複：手動合併訂閱後，多個 proxies 項目使用相同名稱，可能導致引用關係異常。
• 欄位類型錯誤：port 應為數字，allow-lan 應為布林值，不能將它們寫成結構不同的清單或物件。
• 規則順序錯誤：MATCH 應放在規則清單末尾；它通常不會造成語法崩潰，但會讓後續規則永遠無法匹配。
• provider 檔案失效：主設定能解析，不代表引用的代理集合與規則集合一定可讀，還要檢查下載失敗、路徑變更及檔案內容格式。

最快的隔離方式是改用最小設定啟動核心。以下設定不包含節點與訂閱，只用於確認核心能否完成解析並監聽本機連接埠：

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

proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

最小設定可以啟動、原設定無法啟動時，問題就集中在原 YAML、訂閱產生內容或外部 provider；最小設定也失敗，則繼續檢查連接埠、權限與核心本身。測試時應保留原檔案副本，不要用最小設定覆蓋唯一一份訂閱。

第三優先級：處理權限、服務模式與 TUN 啟動失敗

一般系統代理主要監聽本機 TCP 連接埠，所需權限較少；TUN 模式還要建立虛擬網路介面、修改路由表與 DNS，因此更容易遇到權限問題。典型現象是客戶端介面正常、系統代理可用，但開啟「設定」→「TUN 模式」後核心退出，記錄出現 permission denied、operation not permitted、failed to set route 或虛擬介面建立失敗。

Windows：先驗證服務模式

1. 進入客戶端的「設定」→「服務模式」或「系統服務」，檢查服務是否已安裝並正在執行。
2. 服務安裝失敗時，完整退出客戶端，再透過右鍵選單選擇「以系統管理員身分執行」，僅用於完成服務安裝或修復。
3. 開啟 services.msc，確認對應客戶端服務的狀態。服務名稱由具體客戶端決定，應以介面提示為準。
4. 服務修復後重新以一般使用者身分啟動客戶端，再測試 TUN，避免長期依賴系統管理員方式執行桌面介面。

如果舊客戶端解除安裝後留下同類服務，新客戶端可能無法註冊自己的服務。此時先使用舊客戶端提供的解除安裝服務功能，再安裝目前客戶端的服務元件。不要依名稱批次刪除系統網路驅動程式，以免影響 VPN、虛擬機器與容器網路。

macOS：檢查網路延伸功能與系統授權

首次啟用 TUN 或系統延伸功能時，macOS 可能要求系統管理員確認。可進入「系統設定」→「隱私權與安全性」查看遭系統攔截的元件提示，並在「系統設定」→「網路」→「VPN 與過濾器」查看相關網路設定。將應用程式移至「應用程式」目錄後再啟動，可減少從暫時掛載目錄執行造成的路徑與權限變化。

Linux：確認可執行權限與網路能力

AppImage 首次執行前需要可執行權限，可透過檔案管理器的屬性面板設定，也可以執行：

chmod +x ./Clash-Client.AppImage
./Clash-Client.AppImage

TUN 所需能力取決於客戶端的服務設計。有些客戶端使用 systemd 服務管理 mihomo，有些則需要另外設定網路能力。應優先使用客戶端內建的服務安裝入口，而不是長期以 root 啟動整個圖形介面。若記錄提示 /dev/net/tun 不存在，可先檢查系統是否提供 TUN 裝置：

ls -l /dev/net/tun
ip tuntap list
systemctl status NetworkManager

第四優先級：修復核心檔案與版本不相容

圖形客戶端與 mihomo 核心是兩個層次。介面升級成功，不代表核心檔案也已正確替換。安全軟體隔離、磁碟寫入中斷、舊程序鎖定檔案，以及手動替換不同架構的二進位檔，都可能讓客戶端在「啟動核心」階段失敗。記錄常見表現包括找不到檔案、拒絕執行、程序退出碼異常，或 x64 系統誤用了 ARM64 建置版本。

確認系統架構

• Windows 可在「設定」→「系統」→「系統資訊」→「系統類型」查看 x64 或 ARM64。
• macOS 可在「蘋果選單」→「關於這台 Mac」查看晶片；Apple 晶片對應 arm64，Intel 處理器對應 x64。
• Linux 可執行 uname -m；x86_64 對應 x64，aarch64 對應 ARM64。

如果客戶端提供「設定」→「核心」→「重新下載」或「檢查更新」，應先使用內建入口。介面無法開啟時，可重新安裝與系統架構相符的完整客戶端套件。安裝前退出客戶端與 mihomo，避免舊程序占用正在替換的檔案。只複製單一核心時，還要考慮客戶端支援的 API 與設定欄位，版本差距過大可能出現欄位無法識別的情況。

mihomo 可以在終端機中直接查看版本，能正常輸出版本資訊至少代表檔案可執行：

mihomo -v

若終端機提示格式錯誤或無法執行，優先核對架構；若提示檔案不存在，檢查客戶端設定中記錄的核心路徑；若程序啟動後立即返回，則使用最小設定執行測試，將「核心本身問題」與「設定載入問題」分開。

第五優先級：補齊系統元件並重設應用程式資料

部分 Windows 客戶端使用 WebView2 顯示介面，另一些則基於 Electron 或其他桌面執行環境。視窗完全不出現、介面透明，或事件檢視器記錄 WebView 載入失敗時，可以進入「設定」→「應用程式」→「已安裝的應用程式」，確認是否存在 Microsoft Edge WebView2 Runtime。若客戶端安裝說明明確要求 Visual C++ 2015–2022 Redistributable，也應安裝與應用程式架構相符的 x64 或 ARM64 版本。

Windows 的「事件檢視器」→「Windows 記錄」→「應用程式」可查看閃退當下的錯誤。重點記錄「錯誤應用程式名稱」、「錯誤模組名稱」及例外代碼。若錯誤模組指向客戶端自己的可執行檔，優先重新安裝客戶端；若指向 WebView 或系統執行庫，優先修復對應元件。

安全重設應用程式資料

當連接埠、設定、權限、核心與執行環境都正常，但客戶端仍在載入介面階段閃退，可測試新的應用程式資料目錄。做法是完全退出程式，將原資料目錄重新命名為帶日期的備份目錄，例如從 clash-client 改為 clash-client-backup-20260818，然後重新啟動。客戶端會產生一套初始資料。

1. 新資料目錄可以啟動：舊目錄中的介面設定、資料庫或快取可能存在異常。
2. 新資料目錄仍然閃退：故障更可能位於安裝檔案、系統元件或顯示卡渲染層。
3. 恢復訂閱時只匯入設定檔，不要立刻把整個舊目錄覆蓋回去。
4. 每恢復一項就重新啟動一次，方便確認是哪個檔案重新引入故障。

對於升級後出現的問題，還應檢查是否同時保留了免安裝版與安裝版。兩個副本可能讀取不同資料目錄，卻共用相同連接埠與系統代理設定。保留一套明確使用的安裝版本，清理舊捷徑，並從「工作管理員」→「啟動應用程式」確認只有目前客戶端設定為開機啟動。

依症狀執行的完整修復順序

情況一：點擊圖示後完全看不到視窗

1. 等待 10 秒，開啟工作管理員或活動監視器確認程序是否存在。
2. 結束客戶端與 mihomo 的殘留程序，只重新啟動一次。
3. 查看系統事件記錄，確認是否為 WebView2、執行庫或應用程式模組錯誤。
4. 將應用程式資料目錄重新命名備份，使用初始資料啟動。
5. 仍然失敗時，重新安裝與 x64 或 ARM64 架構相符的客戶端。

情況二：介面開啟，但核心始終顯示「停止」

1. 查看「記錄」頁面最早出現的 error 記錄，不要只看最後一行。
2. 檢查 7890、7891、9090 或設定中的實際連接埠。
3. 使用 mihomo -t -f 驗證目前的 YAML。
4. 改用 mixed 連接埠 17890 的最小設定進行測試。
5. 執行 mihomo -v，確認核心檔案與系統架構。

情況三：只有 TUN 模式無法開啟

1. 先關閉 TUN，確認一般系統代理能夠啟動。
2. Windows 修復客戶端服務模式；macOS 檢查網路延伸功能；Linux 檢查 /dev/net/tun。
3. 退出其他 VPN、虛擬網卡工具與第二款代理客戶端後再測試。
4. 檢查記錄中的路由、DNS 與介面錯誤，記下具體介面名稱。
5. 服務修復後重新啟動系統，再只啟用一個網路接管工具。

情況四：更新訂閱後立即閃退或核心退出

1. 切回上一個可用設定，暫停自動更新訂閱。
2. 驗證新 YAML 的縮排、欄位類型與策略組引用。
3. 分別測試主設定、proxy provider 與 rule provider。
4. 清理失敗的暫存下載檔案後重新更新一次。
5. 確認訂閱產生的欄位受到目前 mihomo 版本支援。

恢復啟動後再檢查代理狀態

客戶端能開啟不代表網路接管已恢復。啟動成功後，先在記錄中確認設定載入完成、代理連接埠開始監聽，再進入「代理」頁面選擇策略組。接著依「設定」→「系統代理」開啟系統代理，或在服務狀態正常後單獨啟用 TUN。不要同時變更設定、DNS、TUN 與規則模式，否則出現新問題時很難定位變更來源。

可以先造訪一個直連網站與一個需要經過代理規則的網站，觀察記錄中的規則命中情況與策略組名稱。若介面正常但所有請求都失敗，應轉向排查節點可用性、訂閱有效期限、DNS 解析與規則匹配，而不是繼續重複安裝客戶端。