Clash Verge 開啟即閃退：日誌位置、殘留設定與連接埠衝突的處理方式

先分辨介面退出、核心啟動失敗與背景執行

「Clash Verge 無法開啟」可能代表三種不同層面的故障：桌面介面未能建立視窗、mihomo 核心啟動失敗，或程式已在系統匣執行但主視窗沒有顯示。連接埠被占用通常會先影響核心，不一定會讓整個桌面程式退出。先確認程序狀態，再決定要處理設定還是修復執行環境。

本文主要排查 Windows 版 Clash Verge Rev。舊版 Clash Verge 與 Clash Verge Rev 屬於不同維護分支，設定目錄和選單名稱可能不同；請勿只憑桌面捷徑名稱判斷版本。若能開啟視窗，請從「設定」→「關於」記下完整版本號，並記錄 Windows 版本、系統架構和最近一次變更。下列連接埠僅供示範，實際值請以本機設定為準。

先恢復不依賴代理的網路連線

如果用戶端退出後網頁也無法開啟，請先檢查 Windows「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」。確認 Proxy 確實由該用戶端設定，且對應的本機監聽已停止後，再關閉「使用 Proxy 伺服器」。例如，系統仍指向 127.0.0.1:7890，但沒有程式監聽該連接埠，遵循系統 Proxy 設定的應用程式就可能無法連線。

日誌位置：先找出啟動當下的第一筆錯誤

若能進入介面，請優先使用「設定」中的設定目錄或日誌目錄入口；不同發行版本的按鈕名稱可能略有差異。這比根據資料夾名稱猜測可靠。若完全無法啟動，再從作業系統的資料目錄尋找。

Windows 常見資料目錄

Clash Verge Rev 常見的使用者設定根目錄如下。按 Win + R，貼上路徑後按 Enter；若目錄不存在，請開啟 %APPDATA%，依資料夾修改時間尋找實際安裝的分支。

%APPDATA%\io.github.clash-verge-rev.clash-verge-rev

該目錄通常會看到 logs、profiles 和數個 YAML 檔案。日誌子目錄和檔名會隨版本而異，請依「剛才啟動的時間」排序查看；不要假設每個版本都有相同名稱的日誌。舊版 Clash Verge 的資料目錄可能使用 io.github.clash-verge.clash-verge，也可能因安裝方式不同而有所差異。

• 應用程式日誌：檢查介面初始化、檔案讀寫、服務通訊與背景啟動異常。
• 核心日誌：檢查 YAML 解析、規則提供者載入、DNS 監聽與連接埠繫結失敗。
• 系統事件：若應用程式日誌沒有更新，按 Win + R 輸入 eventvwr.msc，前往「Windows 記錄」→「應用程式」，尋找同一時間的錯誤，並記下故障應用程式和故障模組名稱。

macOS 的應用程式資料通常位於 ~/Library/Application Support/，Linux 則通常從 ~/.config/ 開始尋找。實際目錄仍應以用戶端入口、應用程式識別碼和發行套件說明為準，請勿將 Windows 路徑直接套用到其他平台。

依錯誤關鍵字分類，別只看最後一行

先重現一次問題，再查看該次啟動最早出現的明確錯誤。後續的「無法連線至核心」可能只是前面設定解析失敗或連接埠衝突所造成的結果。保留錯誤前後約 20 行，通常比只截取一行更容易判斷原因。

• address already in use 或 bind：優先檢查監聽位址與連接埠。
• yaml、unmarshal、parse：優先檢查設定語法、欄位型別與合併結果。
• permission denied 或 Access is denied：檢查遭拒的檔案、服務或裝置操作。
• WebView2 或系統事件中的執行階段異常：改從介面執行環境著手排查，不要先修改代理規則。

殘留設定與損毀檔案：備份後以最精簡設定啟動

重新安裝用戶端後仍然閃退，常見原因是使用者資料目錄仍被保留。安裝程式更新的是程式檔案，不一定會重設訂閱索引、介面狀態和覆寫設定。建議先隔離舊資料以確認問題來源，而不是直接刪除所有檔案。

完整備份，再隔離設定目錄

1. 透過系統匣結束用戶端。在工作管理員確認相關桌面程序已結束；若有背景服務，也請依用戶端提供的方式停止服務。不要結束來源不明的系統程序。
2. 將整個使用者資料目錄複製到獨立的備份位置。備份可能包含訂閱網址和金鑰，請妥善限制存取權限。
3. 將原資料目錄重新命名，例如在目錄名稱後加上 .backup-20260915。保留原始檔案內容，以便還原。
4. 重新啟動同一個用戶端。通常會建立初始資料；先不要匯入訂閱或啟用 TUN，只確認視窗和基本核心能否正常啟動。

若使用全新資料可以啟動，問題範圍便縮小到舊設定或舊狀態。若仍然退出，請保留新產生的日誌，繼續檢查執行環境。不要立即整個覆蓋回舊目錄，否則可能再次引入相同問題。

依序還原訂閱、覆寫設定與 TUN

先只還原一份可信任的訂閱，確認核心能啟動；再逐項還原規則、設定合併和指令碼，最後才還原 TUN 與服務設定。每完成一項就重新啟動驗證。訂閱原始檔能解析，不代表套用覆寫後的最終設定仍然有效。

• YAML 縮排請使用空格，不要使用 Tab；檢查清單項目前的連字號，以及冒號後是否有空格。
• 留意連接埠欄位誤填文字、陣列誤寫成字串，以及策略群組引用不存在的節點或群組。
• 確認自訂規則結尾的策略群組名稱，與目前訂閱中的名稱完全一致。
• 遷移舊核心設定時，請依目前 mihomo 支援的功能檢查欄位；舊版能成功解析，不代表目前版本也相容。

若要透過命令列再次確認，可用最終設定的副本執行核心設定測試。下列命令要求目前目錄中有對應的 mihomo 執行檔和 config.yaml；此命令只測試設定，不會啟動常駐代理。

.\mihomo.exe -t -f .\config.yaml

測試時應盡量使用用戶端實際呼叫的相同版本核心。含有規則提供者或外部檔案的設定也會受到工作目錄和資源路徑影響，因此應搭配用戶端日誌判讀命令列結果。不要把訂閱原始檔的測試結果當成最終合併設定的測試結果。

連接埠被占用：確認監聽程序，再修改衝突項目

常見衝突包括 HTTP/SOCKS 混合代理連接埠、控制介面連接埠，以及啟用本機 DNS 後的 DNS 監聽連接埠。以下以 7890 和 9090 示範查詢；這些並非所有 Clash Verge Rev 版本的預設值。

在 Windows 查詢 PID 與程式名稱

在 PowerShell 中執行下列命令。第一個命令會列出對應連接埠的 TCP 監聽和 PID；取得 PID 後，再用第二個命令查看程式資訊。請將範例中的 4321 替換為實際查詢結果。

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

Get-Process -Id 4321 | Select-Object Id,ProcessName,Path

沒有列出連接埠，只代表查詢當下沒有符合條件的 TCP 監聽。若是 DNS 或其他 UDP 衝突，還需要檢查 UDP；例如實際設定使用 1053 時：

Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

若監聽程序屬於另一個代理用戶端，請先正常退出該用戶端及其背景服務。若屬於目前用戶端的核心，可能是重複執行個體或服務模式仍在運作；請檢查程序路徑、啟動時間和日誌，不要看到 mihomo 就強制結束。權限不足時，查詢結果中的程式路徑可能會空白。

修改代理連接埠後，同步更新系統設定

若確定需要同時執行多個用戶端，可將其中一個用戶端的混合連接埠從 7890 改為未被占用的 7897。請透過目前版本的設定入口或持續生效的覆寫設定修改，避免只編輯下次啟動時會重新產生的檔案。

變更連接埠後，請將該用戶端的系統 Proxy 關閉再重新開啟，並檢查瀏覽器、命令列環境變數和其他應用程式中的手動 Proxy 位址。控制介面連接埠不能當作 HTTP 代理連接埠使用；即使 9090 正在監聽，也不代表將應用程式代理指向該連接埠就能正常傳輸流量。

分層檢查執行階段、權限與 TUN 服務

介面在核心啟動前退出：檢查 WebView2 與系統事件

Windows 版 Clash Verge Rev 的介面依賴 WebView2。若視窗空白或建立視窗時立即退出，且事件或日誌指出問題與 WebView2 有關，可在 Windows「設定」→「應用程式」→「已安裝的應用程式」檢查 Microsoft Edge WebView2 Runtime。請依 Microsoft 官方安裝程式和目前用戶端的發行說明修復或安裝，然後重新啟動應用程式。

只有明確出現 VCRUNTIME140.dll、MSVCP140.dll 等缺漏訊息時，才進一步檢查 Microsoft Visual C++ 2015–2022 Redistributable，並依報錯程式的架構選擇安裝套件。不要從 DLL 下載網站單獨複製檔案，也不要把所有閃退都歸因於同一個執行階段。

一般模式可正常啟動，只有啟用 TUN 才失敗：檢查服務層

TUN 模式涉及虛擬網卡、路由和較高權限，與系統 Proxy 並非同一個開關。若關閉 TUN 後介面和核心都能正常運作，排查重點應放在用戶端服務、虛擬網卡初始化，以及其他 VPN 的路由競爭，而不是繼續清理訂閱。

1. 關閉 TUN，確認一般代理模式可以建立連線。
2. 在用戶端「設定」中確認服務模式狀態，並使用目前版本提供的安裝或修復入口處理。
3. 暫時退出其他 VPN 或虛擬網卡接管工具，但請保留必要的企業網路軟體設定。
4. 重新啟用 TUN，查看本次失敗對應的第一筆服務或核心錯誤。

修復後驗收與再次發生時的紀錄

視窗能開啟只是第一步。修復完成後，還應確認核心、監聽、設定還原，以及退出後的網路狀態。每次只還原一項變因，才能判斷故障究竟來自訂閱、覆寫設定、連接埠還是服務。

• 冷啟動：正常退出後重新開啟，確認視窗和系統匣狀態一致，且日誌沒有重複的啟動錯誤。
• 載入設定：確認目前訂閱、策略群組和規則都已載入，而非只停留在初始空白設定。
• 監聽與請求：確認實際代理連接埠，再查看用戶端連線記錄中的目標、規則和策略群組是否符合預期。
• 單獨驗收 TUN：需要使用 TUN 時再啟用，檢查相關應用程式的網路連線和 DNS 行為；不要把「系統 Proxy 可用」當成 TUN 已通過驗證。
• 退出後還原：退出後確認系統 Proxy 沒有繼續指向已關閉的本機連接埠。

若問題仍然重現，請整理用戶端完整版本號、核心版本、系統版本、安裝方式、重現步驟和已移除敏感資訊的日誌。明確註明「使用全新資料目錄是否會重現」、「關閉 TUN 是否會重現」和「是哪個程序占用連接埠」，比籠統描述「一開啟就閃退」更有助於診斷。安裝與設定流程可參考使用指南，名詞差異請參閱術語表。