Clash 啟動閃退排查：設定檔錯誤、連接埠占用與權限問題

Clash 客戶端啟動後立即退出，通常不是單一故障。圖形介面、mihomo 或 Clash 核心、設定檔、監聽連接埠和 TUN 元件會依序初始化，其中任何一步失敗，都可能表現為視窗閃現後消失、系統匣圖示消失，或程序在幾秒後結束。反覆雙擊很難取得新資訊，正確做法是先判斷退出發生在哪一層。

先區分介面閃退、核心退出與背景殘留

啟動故障可以先依現象分成三類。第一類是視窗完全沒有出現，工作管理員或活動監視器中也沒有程序，重點檢查應用程式檔案、執行權限和系統安全性提示。第二類是介面出現後立即關閉，常見原因是設定載入失敗或圖形介面本身的資料損壞。第三類是視窗消失但背景程序仍在，此時可能只是客戶端最小化到系統匣，或舊程序占用了新執行個體需要使用的連接埠。

用 60 秒完成初步判斷

關閉系統代理和 TUN 模式，避免排查期間網路流量繼續進入失效的連接埠。
開啟工作管理員、活動監視器或系統監視器，結束名稱中包含 Clash、mihomo 或對應客戶端名稱的殘留程序。
再次啟動客戶端，觀察程序持續時間。少於 2 秒便退出，優先檢查執行權限和應用程式檔案；執行 2 至 10 秒後退出，優先檢查設定檔與連接埠。
檢查客戶端資料目錄中的記錄。若介面可以短暫開啟，可進入「設定」→「記錄」或「設定」→「執行記錄」，將記錄層級暫時調整為 info。
如果圖形介面沒有留下記錄，直接在終端機執行核心並進行設定測試，讓錯誤輸出保留在視窗中。

啟動現象	優先檢查	典型訊息
雙擊後完全沒有程序	檔案完整性、執行權限、系統攔截	Permission denied、無法開啟應用程式
執行數秒後退出	設定語法、訂閱內容、連接埠占用	parse config、address already in use
一般模式可用，開啟 TUN 就退出	TUN 驅動程式、服務權限、路由介面	start tun failed、operation not permitted
視窗消失但網路仍可用	系統匣區域、背景程序、單一執行個體限制	程序仍在監聽 7890 或 9090

設定檔錯誤：先測試 YAML，再復原最小設定

Clash 和 mihomo 在建立監聽連接埠前會讀取 YAML 設定。縮排錯誤、欄位類型錯誤、規則格式不完整、代理群組引用不存在的節點，都可能讓核心直接退出。若在訂閱剛更新後開始閃退，或手動修改設定後無法啟動，應優先檢查設定檔。

常見 YAML 錯誤

使用 Tab 縮排。YAML 應使用空格，同一層級的欄位必須保持相同縮排。
冒號後缺少空格，例如將 mixed-port: 7890 寫成 mixed-port:7890。
規則缺少策略名稱，例如只寫 DOMAIN-SUFFIX,example.com，沒有最後的代理群組。
proxy-groups 引用了不存在的節點或群組名稱，特別是重新命名節點後未同步修改群組成員。
從網頁複製內容時混入全形標點，導致英文冒號、逗號或引號被替換。
將 mihomo 專用欄位交給較舊的 Clash 核心讀取，核心無法識別目前的設定結構。

在終端機執行設定測試

mihomo 支援透過 -t 測試設定，並透過 -f 指定檔案。Windows 使用者可在核心所在目錄開啟 PowerShell，macOS 與 Linux 使用者則在終端機進入對應目錄。以下指令只會測試設定，不會長時間啟動代理服務：

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

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

# 使用舊版 Clash 核心時
./clash -t -f ./profiles/config.yaml

如果輸出包含具體行號，先檢查該行以及上方 3 至 5 行。YAML 解析器經常在讀取下一個欄位時，才確認前一段結構有誤，因此錯誤行不一定是問題真正開始的位置。若語法測試通過但客戶端仍退出，再查看是否出現代理群組為空、provider 下載失敗或規則集路徑無法讀取等執行期錯誤。

用最小設定判斷問題範圍

不要直接在原檔案上連續嘗試修改。先複製原設定，再建立只包含連接埠、模式和空規則的暫時設定。這份設定可以驗證核心能否完成基本啟動：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

最小設定可以啟動，表示核心檔案與基本權限大致正常，故障集中在原訂閱或自訂段落。接下來依照 dns、proxy-providers、rule-providers、tun 的順序逐段復原，每次只增加一段並重新測試。若最小設定也無法啟動，則轉向檢查連接埠、權限和核心檔案。

7890 連接埠被占用：找出程序，不要只修改數字

mixed-port: 7890 表示 Clash 同時在 7890 接收 HTTP 與 SOCKS 代理連線。如果舊執行個體尚未退出、另一個代理程式正在執行，或系統服務已經監聽該連接埠，新核心會回報 address already in use、bind failed 或類似訊息。部分圖形客戶端不會顯示錯誤，看起來就像啟動閃退。

Windows 檢查 7890

在 PowerShell 中執行以下指令。第一條會回傳占用連接埠的程序 ID，第二條則依該 ID 查看程式名稱：

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id 4321

將範例中的 4321 替換為第一條指令顯示的 OwningProcess 數值。也可以使用系統內建指令查看監聽項目：

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

macOS 與 Linux 檢查 7890

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

lsof 適用於 macOS 和多數 Linux 環境，ss 則常見於 Linux。確認占用者是舊版 Clash 或 mihomo 程序後，先從客戶端正常退出；無法退出時再結束對應的 PID。不要直接結束名稱不明的系統服務，應先確認可執行檔路徑和用途。

改用其他連接埠時同步修改三個位置

如果 7890 必須留給其他程式，可以將 Clash 的 mixed-port 改為 7893，但設定檔、客戶端設定和系統代理必須一致：

在設定檔中設定 mixed-port: 7893。
進入「設定」→「參數設定」→「連接埠」，確認混合連接埠顯示為 7893。
重新開啟系統代理，檢查 HTTP 與 SOCKS 位址是否指向 127.0.0.1:7893。

除了 7890 外，還應檢查 7891、7892 和 9090。舊設定常將 7891 用作 SOCKS 連接埠、7892 用作重新導向連接埠、9090 用作外部控制介面。只要其中一個必要的監聽項目發生衝突，核心同樣可能終止。排查時應以目前 YAML 中實際啟用的連接埠為準。

TUN 模式啟動失敗：檢查驅動程式、服務與管理員權限

一般系統代理只需要在本機監聽連接埠，TUN 模式還要建立虛擬網路介面、修改路由並處理 DNS，因此需要更高權限。若關閉 TUN 後客戶端能穩定執行，一開啟「設定」→「網路」→「TUN 模式」就退出，問題通常出在驅動程式、服務權限或殘留的虛擬網卡。

Windows：檢查服務模式與 Wintun 介面

先以管理員身分啟動一次客戶端，完成服務或虛擬網卡初始化。之後是否需要管理員權限，取決於客戶端採用的服務模式。
進入「裝置管理員」→「網路介面卡」，檢查是否存在帶有警告標記的 Wintun、Mihomo 或 Clash 虛擬介面。
如果客戶端提供「設定」→「服務模式」，先停止舊服務，再重新安裝服務，避免介面版本與背景服務版本不一致。
確認 Windows 的 Internet Connection Sharing 或其他虛擬網路軟體沒有持續重建衝突的路由。

記錄中出現 Access is denied、operation requires elevation 時，表示目前程序缺少權限；出現 device already exists 時，應檢查殘留介面；出現 start tun failed 但沒有更多資訊時，可以將記錄層級改為 debug 後重試一次，再恢復為 info，避免長期產生大量記錄。

macOS：確認網路延伸功能授權

macOS 客戶端首次啟用 TUN 時，可能會要求安裝輔助服務或允許網路延伸功能。開啟「系統設定」→「隱私權與安全性」，檢查底部是否有待確認的系統軟體提示；再進入「系統設定」→「網路」→「VPN 與過濾器」，確認對應設定沒有處於反覆連線狀態。升級客戶端後若輔助服務版本未同步，應在客戶端設定中重新安裝服務，而不是手動複製舊的輔助程式。

Linux：檢查 TUN 裝置與權限能力

先確認系統存在 /dev/net/tun，再檢查目前帳戶是否有建立介面和修改路由的權限：

ls -l /dev/net/tun
ip tuntap list
ip route
getcap ./mihomo

直接從終端機執行時，缺少網路管理能力可能會出現 operation not permitted。使用 systemd 服務時，還要檢查服務單元的使用者、能力限制與工作目錄。不要同時執行桌面客戶端 TUN 和另一個 mihomo systemd 服務，兩者可能爭用介面名稱、DNS 連接埠或策略路由。

Android 與 iOS：重新建立 VPN 授權

行動裝置上的 TUN 通常透過系統 VPN 介面實現。在 Android 上可進入「設定」→「網路和網際網路」→「VPN」，移除失效的常駐連線後重新授權；同時檢查是否已有其他 VPN 應用程式占用系統唯一的 VPN 通道。在 iOS 上可進入「設定」→「一般」→「VPN 與裝置管理」查看設定狀態。若應用程式一啟動連線就被系統終止，還應檢查系統電池最佳化和背景執行限制。

核心檔案遺失或損壞：確認路徑並重新安裝對應版本

圖形客戶端通常不是代理核心本身。介面會在啟動時呼叫 mihomo、Clash 或客戶端隨附的核心檔案。如果核心被移動、升級中斷或架構不相容，介面可能找不到可執行檔，或啟動核心後立即收到異常退出狀態。

先確認客戶端實際呼叫的核心

開啟客戶端的「設定」→「核心」或「設定」→「版本資訊」，記錄核心名稱、版本和檔案路徑。
檢查路徑指向的檔案是否存在，以及檔案大小是否明顯為 0 KB。
在終端機直接執行 mihomo -v 或 clash -v，確認能夠輸出版本資訊。
核對系統架構。Windows 與 Linux 常見為 amd64 或 arm64，Apple 晶片的 macOS 應選擇 arm64 架構。

# Windows PowerShell
& ".\mihomo.exe" -v

# macOS 或 Linux
./mihomo -v
uname -m

如果版本指令也立即退出，先不要繼續修改訂閱。重新安裝與作業系統和 CPU 架構相符的客戶端或核心，再使用最小設定測試。Linux 下還要確認執行位元是否存在；檔案可以讀取但沒有執行權限時，終端機會回傳 Permission denied。

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

客戶端更新後開始閃退，還應排除介面與核心介面不相容的可能性。部分新版設定依賴 mihomo 的新欄位，而舊核心無法讀取；反過來，較舊的圖形介面也可能無法識別新版核心回傳的資料。復原時應優先安裝同一發行套件內配套的介面和核心，不要把多個來源、不同版本的檔案混放在同一個目錄。

客戶端資料損壞：保留設定後重建執行目錄

設定測試通過、連接埠空閒、核心能夠獨立執行，但圖形介面仍閃退時，問題可能位於視窗狀態、資料庫、快取或客戶端本身的設定。此時可以重建應用程式資料，但必須先備份訂閱網址、profiles 設定、自訂規則和腳本。

安全的重建順序

徹底退出客戶端，並確認背景沒有 Clash 或 mihomo 程序。
將設定目錄複製到桌面備份，不要只保留目前的 YAML；provider 檔案和自訂規則也可能需要復原。
將原資料目錄重新命名，而不是立即刪除。例如在目錄名稱後加上 -backup-20260722。
重新啟動客戶端，讓程式建立乾淨的資料目錄。
先匯入一份已確認可用的設定，不要一次複製所有舊快取。
確認啟動穩定後，再逐項復原訂閱和自訂規則。

Windows 應用程式資料通常位於使用者的 AppData 子目錄，macOS 常見於使用者資料庫的 Application Support，Linux 常見於 ~/.config。具體目錄名稱由客戶端決定。可透過客戶端的「設定」→「設定目錄」或記錄中的 home directory、config directory 欄位確認，不應直接依照其他客戶端的目錄名稱刪除。

依平台執行完整復原流程

Windows 復原步驟

關閉「設定」→「網路和 Internet」→「代理伺服器」中的手動代理。
在工作管理員中結束殘留的客戶端與 mihomo 程序。
使用 PowerShell 檢查 7890、7891、7892、9090 是否處於 LISTEN 狀態。
在終端機執行核心版本指令和設定測試指令。
一般代理可以啟動後，再檢查服務模式和 TUN 虛擬介面。
仍然失敗時，備份資料目錄，重新安裝客戶端，並只復原一份已驗證的設定。

macOS 復原步驟

在「系統設定」→「網路」中關閉失效的代理或 VPN 設定。
透過活動監視器結束殘留程序，並使用 lsof 檢查監聽連接埠。
從終端機執行核心，分別驗證版本和 YAML 設定。
檢查「隱私權與安全性」中的授權提示，以及「VPN 與過濾器」中的網路延伸功能。
若一般代理正常但 TUN 失敗，請在客戶端內重新安裝輔助服務。

Linux 復原步驟

檢查是否同時執行桌面客戶端和 systemd 服務。
使用 ss -lntp 查看連接埠，使用 journalctl 查看服務退出原因。
確認核心架構、執行權限、工作目錄與設定檔讀取權限。
關閉 TUN 後測試 mixed-port，再檢查 /dev/net/tun 和路由權限。
修復後只保留一種啟動方式，避免兩個執行個體重複載入同一份設定。

修復後的驗證清單

客戶端不再閃退只代表程序能夠執行，還需要確認代理鏈路、DNS 和規則行為都已恢復。建議依照以下順序驗證，任何一步失敗都先停留在目前層級，不要同時修改多個選項。

客戶端持續執行至少 5 分鐘，記錄中沒有反覆出現 error。
7890 或自訂 mixed-port 處於監聽狀態，程序名稱與目前核心一致。
系統代理位址與 mixed-port 完全一致，例如 127.0.0.1:7890。
切換到規則模式後，DIRECT、代理群組和 MATCH 能依預期命中。
訂閱可以手動更新，更新後執行設定檢查仍然通過。
一般代理穩定後再啟用 TUN，並觀察虛擬介面、預設路由與 DNS 是否正常。
重新啟動作業系統後再測試一次，確認沒有舊服務搶占 7890 或重複啟動核心。

最有效的排查順序是：先用終端機保留錯誤資訊，再測試設定，接著檢查連接埠，最後處理 TUN 和應用程式資料。設定錯誤通常可以透過行號定位；連接埠衝突可以透過 PID 定位；TUN 故障可以透過關閉 TUN 隔離；核心問題則能透過版本指令和最小設定確認。每次只變更一個變數，才能知道哪項操作真正解決了啟動閃退。