Clash 客戶端啟動閃退怎麼辦：檢查設定、權限與殘留程序

先區分閃退、背景執行與視窗未顯示

Clash 圖形用戶端通常由介面程式、代理核心與系統服務組成。按兩下圖示後沒有出現主視窗，不一定代表三個部分都已退出。介面可能縮到系統匣，視窗座標可能保留在已斷線的螢幕上，代理核心也可能仍在背景監聽連接埠。故障排查的第一步不是反覆啟動，而是確認目前的實際狀態。

先檢查 Windows 工作列通知區域、macOS 選單列或 Linux 桌面系統匣。若能看到用戶端圖示，請嘗試從選單開啟主介面。若曾使用雙螢幕、遠端桌面或修改縮放比例，也應檢查視窗是否位於螢幕邊界之外。這類情況屬於介面復原問題，而不是代理核心崩潰。

接著開啟系統程序管理工具，尋找用戶端介面程序，以及名為 Clash、mihomo 或與所用用戶端對應的核心程序。可依下列狀態判斷方向：

• 介面與核心程序都立即消失：優先檢查啟動日誌、設定解析、執行環境與本機資料。
• 介面消失但核心仍在：重點檢查介面日誌、視窗狀態檔案與圖形執行環境。
• 介面存在但核心反覆重啟：重點檢查 YAML 設定、連接埠佔用、TUN 權限及核心版本。
• 程序持續存在但沒有視窗：先從系統匣復原，再考慮重設視窗配置，不要直接刪除全部設定。

從日誌確認用戶端停止在哪個步驟

發生閃退後，日誌通常比彈出視窗更可靠。不同用戶端儲存日誌的位置並不一致，通常可在使用者設定目錄、應用程式資料目錄或用戶端安裝目錄附近找到。檔名可能包含 app、main、service、core 或 runtime。若介面還能短暫開啟，可先在設定或日誌頁面查看實際目錄，避免直接依照其他用戶端的路徑刪除檔案。

讀取日誌時，請從最近一次啟動的時間點開始，不要只搜尋單獨一個 error。有些警告不會阻止啟動，真正導致退出的資訊往往出現在最後幾行。依啟動階段觀察會更容易定位：

1. 介面程式載入設定與視窗狀態。
2. 讀取目前的設定檔或由訂閱產生的設定。
3. 啟動 Clash 或 mihomo 核心。
4. 繫結 mixed-port、HTTP、SOCKS、控制連接埠或 DNS 連接埠。
5. 載入規則集、GeoIP、GeoSite 等資料。
6. 安裝系統代理，或啟動 TUN 與系統服務。

如果日誌停在讀取設定階段，先處理 YAML；出現 address already in use、bind failed 類訊息時，請檢查連接埠；出現 permission denied、operation not permitted 時，請檢查目錄權限或 TUN 權限；出現找不到動態函式庫、WebView 或圖形元件的資訊時，則屬於介面執行環境問題。不要把所有錯誤都歸因於訂閱節點，因為節點無法使用通常只會影響連線，不會讓用戶端在讀取介面前立即退出。

檢查 YAML 設定語法與核心相容性

設定錯誤是核心啟動後立即退出的常見原因。Clash 設定採用 YAML，縮排、清單層級與資料類型都會影響解析。Tab 字元、全形冒號、缺少空格、未閉合的引號，以及將清單寫成一般字串，都可能讓核心拒絕載入。訂閱能夠成功下載，也不代表產生的設定一定適用於目前的核心。

先備份目前設定，再切換至用戶端內建的基本設定或先前確認可用的設定。如果用戶端能夠恢復啟動，故障範圍就已縮小至目前的訂閱、覆寫指令碼或手動修改內容。不要一開始就解除安裝用戶端，因為解除安裝後重新匯入同一份錯誤設定，問題仍會出現。

以下片段展示容易混淆的層級。規則是字串清單，代理群組中的 proxies 也是清單；兩者都必須維持一致的縮排：

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

如果可以直接執行代理核心，可使用核心內建的設定測試參數檢查檔案。mihomo 常見的測試方式如下，實際可執行檔名稱與路徑請以用戶端的安裝內容為準：

mihomo -t -f /path/to/config.yaml

測試結果中的行號通常指向解析失敗附近，但錯誤也可能由前幾行造成。例如某個引號未閉合，解析器可能直到下一個欄位才回報異常。檢查時應向上回看同一個設定區塊，而不是只修改報錯的那一行。

更新後才出現的欄位不相容

Clash Meta 後續由 mihomo 延續，支援的設定欄位與早期 Clash 核心並不完全相同。訂閱轉換規則、TUN 設定、DNS 增強模式、規則集格式與代理協定參數，可能依賴特定核心版本。將為 mihomo 產生的設定交給較舊核心，可能出現 unknown field、unsupported proxy type 或規則提供器載入失敗。

反過來，更新核心後也可能暴露舊設定中原先被忽略的問題。此時應確認用戶端目前使用的核心類型與版本，再檢查訂閱轉換目標。不要隨意刪除陌生欄位來強行啟動，因為刪除 DNS、規則集或代理參數後，雖然語法可能通過，實際分流結果可能已經改變。

檢查執行權限、設定目錄與 TUN 服務

一般系統代理模式通常不要求用戶端始終以系統管理員身分執行，但寫入受保護目錄、安裝系統服務或建立 TUN 網路介面時，需要相應權限。權限不足可能顯示明確提示，也可能讓某些用戶端在服務初始化階段直接退出。

Windows 使用者應確認用戶端沒有放在需要特殊寫入權限的系統目錄中，並檢查安全性原則是否阻止程式寫入自己的設定目錄。若用戶端提供獨立的服務模式，應從用戶端設定中重新安裝或修復服務，而不是長期依賴「以系統管理員身分執行」來繞過問題。服務程式與介面版本不一致時，也可能出現核心啟動失敗或反覆重新連線。

macOS 使用者應確認應用程式仍位於正常的應用程式目錄，且系統的隱私權與安全性設定沒有攔截其網路延伸功能或背景項目。不要透過關閉系統安全機制來處理來源異常的程式；應核對安裝套件來源，並使用符合目前系統架構的版本。Linux 使用者則應檢查設定目錄的擁有者、執行權限，以及 TUN 裝置的存取能力。

單獨驗證 TUN 模式

TUN 模式會建立虛擬網路介面並修改路由，涉及的權限高於一般 HTTP 或 SOCKS 代理。若日誌在 tun、route、interface、service 等位置停止，可先關閉 TUN，只啟用系統代理進行測試。一般代理模式能夠啟動，表示 YAML 主體與介面基本可用，問題集中在 TUN 服務、驅動程式、權限或路由環境。

關閉 TUN 只是診斷步驟。需要恢復 TUN 時，應檢查用戶端的服務安裝狀態、系統中是否殘留舊虛擬網卡，以及其他 VPN、網路過濾軟體是否同時接管路由。多個網路工具同時運作時，即使使用不同連接埠，也可能因路由表與 DNS 接管而發生衝突。

處理連接埠衝突與殘留程序

代理核心啟動時需要監聽設定中的連接埠。常見連接埠包括 mixed-port、port、socks-port、external-controller 與 DNS listen。若舊核心未退出，或其他代理程式使用相同連接埠，新核心便會在繫結階段失敗。若用戶端介面將核心退出視為嚴重錯誤，就可能隨之關閉，看起來像按兩下後閃退。

Windows 可先使用工作管理員結束對應程序，再透過命令檢查指定連接埠：

netstat -ano | findstr :7890

輸出末尾的 PID 可用來確認佔用程序。macOS 與 Linux 可使用：

lsof -nP -iTCP:7890 -sTCP:LISTEN

看到連接埠被佔用後，不要立即結束未知的系統程序。先確認 PID 對應的程式名稱。如果佔用者是上次啟動後留下的 Clash 或 mihomo，可以正常終止；如果是仍需使用的其他服務，則在用戶端設定中更換連接埠，並同步檢查系統代理設定是否引用新連接埠。

殘留程序為何會反覆出現

部分用戶端退出介面時會保留核心，以維持代理連線；也有用戶端在崩潰後未能執行清理邏輯。再次啟動時，舊核心仍持有連接埠、控制介面或設定檔鎖定。正確的處理方式是先從系統匣執行完整退出，等待幾秒後檢查程序。若程序沒有結束，再使用系統工具終止。

重新啟動系統可以清除一般殘留程序，但無法修復自動啟動的舊服務。若每次開機後都出現衝突，應檢查系統啟動項目與服務清單，確認沒有兩個不同版本的用戶端同時自動啟動。保留一個目前使用的用戶端入口，並在其設定中統一管理核心服務。

備份後重建損壞的本機資料

設定語法、權限與連接埠都正常時，應檢查用戶端自行儲存的狀態資料。異常關機、磁碟寫入中斷或跨版本遷移，可能損壞視窗配置、設定索引、資料庫、快取或設定檔。直接刪除整個資料目錄雖然可能讓程式恢復，但也會同時遺失訂閱記錄、覆寫規則與自訂設定，因此應採用逐層隔離的方法。

1. 完整退出介面、核心與相關服務。
2. 找到用戶端實際使用的資料目錄，複製到獨立的備份位置。
3. 先重新命名視窗狀態、快取或日誌目錄，再啟動測試。
4. 若仍然閃退，再重新命名設定資料庫或設定索引。
5. 讓用戶端產生新的資料目錄，確認可以進入主介面。
6. 只恢復必要的訂閱網址與已驗證的設定，不要將整個目錄覆蓋回去。

採用「重新命名而不是刪除」的方式，可以隨時回復，也能透過逐項還原找出損壞檔案。不同用戶端的資料結構差異很大，檔名不能互相套用。特別是基於 Electron、WebView 或其他桌面容器的介面，其快取與核心設定往往位於不同子目錄，應根據日誌與用戶端設定確認用途。

如果新的資料目錄可以啟動，但匯入舊訂閱後再次退出，應回到設定相容性檢查。如果只恢復介面設定就崩潰，則應重點重設視窗配置、主題狀態或本機資料庫。這樣可以把問題限制在單一資料類型，而不是反覆重新安裝。

更新後崩潰：核對架構、核心與執行環境

用戶端更新後首次啟動即閃退，需要同時考慮應用程式架構、內建核心、系統版本與設定遷移。Windows 安裝套件可能區分 x64、ARM64 等架構；macOS 則需要區分 Intel 與 Apple Silicon。選擇不相符的建置版本可能無法啟動，或在載入核心時退出。應在系統資訊中確認處理器架構，再選擇對應版本。

某些圖形用戶端依賴系統 WebView 或特定執行元件。如果日誌明確指出缺少執行環境，應透過作業系統或用戶端文件指定的方式修復元件。僅複製其他電腦上的動態函式庫檔案，容易引入版本與架構不一致，不適合作為穩定的修復方案。

覆蓋安裝也可能保留舊核心、舊服務或舊設定遷移標記。此時可以先備份資料，透過系統解除安裝流程移除舊程式，再安裝目前版本。解除安裝前必須記錄訂閱網址、自訂規則、連接埠與 DNS 設定。重新安裝後先以預設狀態啟動，確認介面與核心正常，再逐項恢復設定。

如果新版系統不再支援目前的用戶端，應選擇仍在維護且適用於該系統的 Clash 圖形用戶端。遷移時應關注設定與核心相容性，而不是只比較介面名稱。mihomo 設定中的部分欄位需要相應核心支援，將舊 Clash 設定遷移至新核心時，也應重新檢查 DNS、TUN 與規則提供器的行為。

依固定順序執行復原流程

閃退排查最容易陷入的問題，是同時修改太多內容。以下順序從低風險操作開始，每一步都能產生明確結論，適用於一啟動就退出、視窗未顯示、更新後崩潰及核心反覆停止等情況。

1. 確認系統匣與程序：判斷是視窗隱藏、介面崩潰還是核心退出。
2. 完整結束舊執行個體：關閉介面、核心與殘留服務，避免重複執行個體爭用連接埠。
3. 讀取最近一次日誌：記錄停止階段與第一個關鍵錯誤，不要只看最後的連鎖錯誤。
4. 切換基本設定：使用用戶端預設設定，確認 YAML 與訂閱是否為故障來源。
5. 測試一般代理模式：暫時關閉 TUN，區分核心啟動問題與系統網路權限問題。
6. 檢查監聽連接埠：確認 mixed-port、控制連接埠與 DNS 連接埠未被其他程式佔用。
7. 核對程式架構與核心版本：確保用戶端、核心、作業系統與設定目標彼此相容。
8. 重建本機狀態：備份後逐項重新命名快取、視窗狀態與資料庫。
9. 最後再重新安裝：先驗證預設狀態，再恢復訂閱與自訂設定。

若完成上述步驟後仍然退出，應保存用戶端版本、作業系統版本、處理器架構、核心類型、關鍵日誌與可重現步驟。提交問題時請隱藏訂閱網址、節點憑證與控制介面密鑰，只保留與錯誤相關的欄位。完整的環境資訊有助於判斷是用戶端介面、mihomo 核心、設定產生器還是系統網路元件發生故障。