Clash 用戶端啟動閃退排查清單：連接埠佔用、設定錯誤與權限問題逐一解決

先判斷是介面關閉，還是 Clash 核心啟動失敗

「雙擊後沒有視窗」「視窗出現一秒後消失」「系統匣圖示存在但無法連線」看似相同，實際上涉及三個不同層級。Clash 圖形用戶端通常由介面程序、Clash Meta（mihomo）核心、系統代理伺服器或 TUN 服務組成。介面程序退出屬於用戶端本身的問題；介面仍在但核心反覆停止，通常與設定、連接埠或核心檔案有關；核心正常執行卻無法存取網路，則應繼續檢查系統代理伺服器、DNS、規則與 TUN，而不是反覆重新安裝用戶端。

排查前先暫時關閉「開機啟動」與「靜默啟動」。如果用戶端可以短暫進入介面，可依序前往「設定」→「一般」關閉開機啟動，再從「工具」或「記錄」頁面複製最近一次啟動記錄。不同用戶端的選單名稱略有差異，常見入口包括「設定」→「記錄」、「工具」→「應用程式記錄」以及「核心」→「執行記錄」。重點是記下退出時間前後最後 20 至 50 行內容。

現象	優先檢查	常見記錄關鍵字
視窗出現後立即消失	應用程式權限、使用者目錄、介面執行環境	permission denied、access denied、panic
介面正常，核心狀態反覆停止	連接埠、YAML、核心檔案	bind、parse、unmarshal、config error
啟用 TUN 後退出	服務權限、驅動程式、路由衝突	tun、service、route、operation not permitted
重新啟動後提示已有執行個體	殘留程序、鎖定檔案	already running、lock、address in use

第一項：檢查 7890、7891 與控制連接埠是否被佔用

連接埠佔用是核心啟動失敗最常見的原因之一。典型設定會使用 HTTP 連接埠 7890、SOCKS5 連接埠 7891，或使用 mixed-port: 7890 合併兩種代理入口。外部控制器常見位址為 127.0.0.1:9090。這些數值並非強制標準，但同一台裝置上的兩個程式不能同時監聽完全相同的位址與連接埠。

Windows 查詢連接埠佔用情況

先完全退出目前的 Clash 用戶端，再開啟 PowerShell 或命令提示字元，依序執行：

netstat -ano | findstr :7890
netstat -ano | findstr :7891
netstat -ano | findstr :9090

如果結果中出現 LISTENING，最右側的數字就是 PID。例如 127.0.0.1:7890 對應 PID 8420，可繼續查詢程序：

tasklist /FI "PID eq 8420"

確認它是舊版 Clash、mihomo、代理軟體或除錯服務後，優先從原程式的退出選單正常關閉。只有確認該程序不再執行其他工作時，才使用以下命令結束：

taskkill /PID 8420 /F

macOS 與 Linux 查詢監聽程序

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

Linux 也可以使用 ss：

ss -lntp | grep -E ':7890|:7891|:9090'

如果必須同時保留兩個用戶端，可在其中一個用戶端的「設定」→「網路」→「連接埠」修改監聽值，例如將 mixed 連接埠改為 7897，控制連接埠改為 9097。修改後還要同步檢查作業系統的代理伺服器設定，避免系統仍指向舊的 127.0.0.1:7890。

第二項：隔離 YAML 設定錯誤與訂閱異常

Clash Meta 會在啟動階段解析 YAML。縮排錯誤、欄位型別不正確、同層級鍵值重複、規則格式錯誤，都可能讓核心直接拒絕設定。記錄中常見的訊息包括 yaml: line 42、cannot unmarshal、proxy group not found 與 invalid mode。此時重點是找出第一個設定錯誤，而不是逐一追查後續的連鎖錯誤。

使用最小設定驗證核心能否獨立啟動

先備份目前的設定，再建立一份只提供本機監聽與直連規則的測試設定：

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

proxies: []

proxy-groups: []

rules:
  - MATCH,DIRECT

這份設定不包含訂閱節點，也不適合日常代理使用。用途是驗證 YAML 解析、連接埠監聽與核心程序能否完成啟動。如果最小設定可以執行，問題基本上位於原設定的 DNS、節點、策略群組、規則或覆寫內容；如果仍然退出，應繼續檢查核心檔案、目錄權限與殘留服務。

逐段還原，不要一次貼回全部內容

先還原 dns 區塊並重新啟動核心，確認目前的 mihomo 版本能識別這些欄位。
再還原 proxies 或訂閱提供者，檢查節點協定參數與憑證欄位。
加入 proxy-groups，確認群組內引用的節點名稱、提供者名稱與其他策略群組確實存在。
最後還原 rules，特別檢查規則集名稱、目標策略名稱與結尾的 MATCH 規則。

YAML 縮排只能用來表達層級，不應在空格縮排中混入 Tab 字元。列表項目的連字號後需要空格，例如 - MATCH,DIRECT。布林值、數字與字串也不能任意互換。某些包含冒號、井號或特殊字元的節點名稱應以引號括起，否則井號後的內容會被視為註解。

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - DIRECT
      - "節點 A"

如果問題發生在訂閱更新後，可在「設定」頁面切換回上一次正常的設定，再關閉自動更新進行比對。訂閱下載成功只代表伺服器回傳了內容，不代表內容一定是可解析的 Clash 設定。回傳登入頁面、HTML 錯誤頁面或遭截斷的 YAML 時，檔案仍可能已寫入磁碟，但核心會在載入階段報錯。

第三項：確認 mihomo 核心檔案與系統架構相符

圖形用戶端本身能夠開啟，不代表核心可執行檔一定可用。更新中斷、檔案遭安全性原則隔離、手動替換了錯誤架構的檔案，都會造成點選「啟動核心」後立即停止。Windows 常見架構為 amd64 與 arm64；搭載 Apple 晶片的 macOS 使用 arm64，Intel Mac 使用 amd64。Linux 也需要區分 amd64、arm64 等建置版本。

進入用戶端的「設定」→「核心」或「核心管理」，先記下目前顯示的核心名稱與版本。例如記錄若顯示 mihomo v1.19.10 windows amd64，至少可以確認檔案已執行並輸出版本；如果連版本資訊都沒有，且記錄只出現「無法啟動程序」或「找不到檔案」，應檢查檔案路徑與執行權限。

優先使用用戶端內建的核心管理功能

先停止系統代理伺服器與 TUN，避免舊核心仍佔用檔案。
完全退出用戶端，並在工作管理員或活動監視器中確認 mihomo 程序已經消失。
重新開啟用戶端，透過「設定」→「核心」→「檢查更新」或「重新下載」，恢復與系統架構相符的核心。
恢復後先載入最小設定，確認核心可以持續執行 30 秒以上，再切換回日常設定。

手動複製核心時，不要只根據檔名判斷架構。錯誤架構在 Windows 上可能回傳「此應用程式無法在您的電腦上執行」，在 Linux 上可能出現 Exec format error。macOS 若提示開發者或隔離屬性相關的阻擋，應先確認檔案來源與用戶端版本，再從系統「隱私權與安全性」頁面查看實際攔截記錄，而不是反覆雙擊。

第四項：處理權限、TUN 服務與受保護目錄

一般系統代理伺服器通常只需監聽本機高位連接埠，而 TUN 模式需要建立虛擬網路介面、修改路由或呼叫系統服務，因此權限要求更高。常見現象是：關閉 TUN 時用戶端穩定，開啟 TUN 後核心立即退出。此時應將 TUN 單獨視為變數進行排查。

Windows：先區分應用程式權限與服務權限

右鍵點選用戶端並選擇「以系統管理員身分執行」可用於一次性診斷，但不應視為所有問題的固定解法。若以系統管理員身分啟動後 TUN 正常、一般啟動失敗，應進入用戶端「設定」→「TUN 模式」或「服務模式」，重新安裝其系統服務，然後退出系統管理員工作階段，再以一般方式測試。

同時檢查應用程式是否位於需要額外寫入權限的目錄。用戶端執行資料不應寫入 C:\Program Files 下的唯讀位置，也不要直接在壓縮檔預覽視窗中執行。將程式完整解壓縮至使用者可寫入的目錄後再啟動，例如使用者目錄下專用的應用程式資料夾。

macOS 與 Linux：檢查可執行權限與網路能力

Linux 手動部署的核心若缺少執行權限，會直接回傳 Permission denied。可先查看權限：

ls -l ./mihomo
chmod u+x ./mihomo

這只能解決檔案執行權限，不代表會自動取得建立 TUN 裝置所需的能力。透過桌面用戶端使用 TUN 時，應優先採用用戶端提供的服務安裝流程；透過 systemd 部署時，則應檢查服務單元的使用者、網路能力、工作目錄與設定路徑。不要一邊執行桌面用戶端，一邊啟動另一個監聽相同連接埠的 systemd 服務。

macOS 可在「系統設定」→「隱私權與安全性」查看遭封鎖的系統擴充功能或應用程式記錄，並在「系統設定」→「網路」檢查是否殘留重複的 VPN 設定。修改後完整退出用戶端再重新啟動，避免舊網路擴充功能狀態繼續影響測試。

第五項：清理殘留程序、鎖定檔案與重複啟動項目

用戶端視窗消失後，mihomo 核心或系統服務可能仍在背景執行。再次啟動時，新執行個體會遇到連接埠佔用、資料庫鎖定或「已有執行個體正在執行」的提示。Windows 可在工作管理員的「詳細資料」頁檢查用戶端主程序、mihomo.exe 與舊版 clash.exe；macOS 使用活動監視器；Linux 可執行：

ps -ef | grep -E 'mihomo|clash'
systemctl --user status mihomo
systemctl status mihomo

如果同一程式同時設定了系統層級服務、使用者層級服務與桌面開機啟動，可能在登入時啟動兩到三次。保留一種啟動方式即可。Windows 可檢查「設定」→「應用程式」→「啟動」以及工作管理員的「啟動應用程式」；macOS 可檢查「系統設定」→「一般」→「登入項目」；Linux 則要同時核對 systemd 服務與桌面環境的自動啟動目錄。

只有確認所有相關程序都已退出後，才能處理鎖定檔案。核心仍在執行時，不要刪除資料庫、快取或執行目錄。若用戶端提供「重設執行狀態」或「清除快取」按鈕，優先使用內建功能。若必須重建使用者資料，先備份訂閱網址、本機 YAML、規則覆寫與應用程式設定，再將原目錄重新命名保留，不要直接永久刪除。

第六項：依固定順序完成一次可重現的排查

閃退問題最容易因「同時修改了五項設定」而拖慢排查。以下順序從低風險、容易驗證的項目開始，每一步只變更一個變數：

完全退出用戶端，確認沒有殘留的介面、mihomo 或 clash 程序。
檢查 7890、7891、9090 等實際設定的連接埠，關閉衝突程序或修改連接埠。
關閉 TUN、系統服務與開機啟動，只保留一般 mixed-port。
載入最小 YAML，觀察核心能否穩定執行至少 30 秒。
記下核心架構與版本，透過用戶端核心管理入口重新部署一次。
逐段還原 DNS、節點、策略群組與規則，每次還原後重新啟動並查看記錄。
最後重新開啟系統代理伺服器，再測試 TUN 與開機啟動。

每次測試都記錄「操作、結果、最後一則錯誤記錄」。例如：「連接埠從 7890 改為 7897，最小設定正常執行 60 秒；切回訂閱後出現第 184 行解析錯誤」。這類記錄可以迅速將問題縮小至設定，而不是籠統歸因於用戶端版本。

什麼情況下應重新安裝用戶端

只有在介面程序本身無法開啟、應用程式檔案遺失、內建核心管理無法恢復，或使用者資料目錄在最小設定下仍持續出現讀寫錯誤時，重新安裝才是合理的步驟。重新安裝前先退出系統代理伺服器與 TUN 服務，備份必要設定，再解除安裝舊版本。安裝後不要立即匯入所有舊資料，先使用預設設定啟動一次，再匯入一份已確認可解析的設定。

什麼情況下不需要重新安裝

記錄明確提示 address already in use：解決連接埠衝突即可。
記錄提供 YAML 行號：修復設定結構或切回正常設定。
只有開啟 TUN 後失敗：處理服務權限、驅動程式或路由衝突。
訂閱更新後開始退出：回復設定並檢查訂閱回傳內容。
背景已有 mihomo 程序：停止重複執行個體並整理啟動項目。