Clash Verge 開啟即閃退？啟動崩潰排除與修復教學

先釐清：視窗崩潰、背景常駐，還是核心啟動失敗

Clash Verge 的介面程序、代理核心與系統服務是不同元件。視窗消失不一定代表整個用戶端都已結束；視窗正常顯示但核心啟動失敗，也不能直接歸因於 WebView2。請先記下作業系統版本、用戶端完整版本、安裝檔架構，以及故障發生在更新後、匯入訂閱後，還是首次安裝時。

舊版 Clash Verge 與後續維護的 Clash Verge Rev 不應視為同一個發行版本。兩者的資料目錄、服務名稱和設定標籤可能不同。若能進入介面，請在「設定」頁面的版本資訊區記下版本；若無法進入，請從安裝檔名稱或執行檔內容確認，不要只憑桌面捷徑名稱判斷。

1. 檢查工作列通知區域；Windows 可開啟隱藏圖示，macOS 請查看選單列。
2. 結束用戶端後，再查看工作管理員或活動監視器。只結束已確認屬於該用戶端的殘留程序。
3. 啟動一次並記下確切時間。不要連續按兩下，否則單一執行個體鎖定與多筆啟動記錄會影響判斷。

第一步：在 Windows 檢查 WebView2 與應用程式錯誤

Windows 版 Clash Verge 介面仰賴 WebView2。Microsoft Edge 瀏覽器能正常開啟，不代表 WebView2 Runtime 一定正常。若主視窗白畫面、出現 WebView2 建立失敗提示，或崩潰記錄涉及 WebView2 元件，應先處理執行環境，而非反覆修改訂閱。

修復執行階段的步驟

1. 結束用戶端。在 Windows 11 開啟「設定」→「應用程式」→「已安裝的應用程式」，搜尋 Microsoft Edge WebView2 Runtime。部分系統的應用程式清單顯示方式不同，搜尋不到不能單獨作為未安裝的判斷依據。
2. 若項目提供「修改」或修復選項，請依照提示操作；若沒有，請使用 Microsoft 官方提供的 Evergreen WebView2 Runtime 安裝程式進行修復或安裝。離線環境可使用相應架構的獨立安裝程式。
3. 安裝完成後重新啟動用戶端；若安裝程式要求重新啟動系統，請先儲存工作再重新開機。
4. 若仍然閃退，按下 Win + R，輸入 eventvwr.msc，開啟「Windows 記錄」→「應用程式」，依剛才記下的時間尋找錯誤。

來源為 Application Error、事件識別碼為 1000 的記錄可供參考，但並非每次故障都會出現。請保留「錯誤應用程式名稱」、「錯誤模組名稱」與「例外狀況代碼」。只看到 ntdll.dll 並不能斷定系統檔案損毀，它可能只是例外狀況最後發生的位置。

白畫面與真正閃退要分開處理

若視窗白畫面但程序仍在執行，請優先保留介面記錄，再檢查執行階段與使用者資料。若連程序都沒有留下，也要查看系統的應用程式錯誤記錄。不要直接套用網路上流傳的停用 GPU 參數到所有版本；不同組建未必接受相同參數，未經確認的啟動參數可能完全沒有生效。

WebView2 僅適用於 Windows。macOS 使用系統的 WebKit；Linux 版本通常依賴 WebKitGTK 等系統元件，無法透過安裝 Windows 執行階段修復。

第二步：檢查連接埠占用，區分代理連接埠與控制連接埠

記錄中出現 address already in use 或 Only one usage of each socket address 時，請先檢查監聽連接埠。連接埠占用通常會導致核心啟動失敗，不一定會讓介面崩潰。若介面也關閉，請繼續檢查介面記錄，不要把兩種現象混為一談。

設定中的 mixed-port 是混合代理入口，external-controller 則是控制介面。以下以 7897 和 9090 示範查詢，這些數值並非所有版本的固定預設值；請替換為記錄或目前設定檔中的實際連接埠。

Windows：先找出監聽程序

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

Get-Process -Id 4321

在 PowerShell 執行第一個指令，再將第二個指令中的 4321 換成實際的 OwningProcess。沒有輸出只表示查詢當下這些 TCP 連接埠沒有監聽，不能證明核心的其他連接埠也正常。不要照著範例 PID 結束程序。

macOS 與 Linux：檢查監聽程序

# macOS
lsof -nP -iTCP:7897 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7897'
ss -ltnp 'sport = :9090'

• 如果占用連接埠的是另一個代理用戶端，請先從其系統匣或選單列正常結束，再重新測試。
• 如果是上次啟動後殘留的核心，請先確認其檔案路徑與歸屬，避免誤停其他使用者或軟體的服務。
• 確實需要更改連接埠時，請在用戶端支援的連接埠設定中調整；若有覆寫設定，也要檢查最後生效的值，不要只修改訂閱原始檔。

變更代理連接埠後，瀏覽器擴充功能、終端機的代理環境變數及其他手動設定也要同步更新。調整控制連接埠後，用戶端與核心的連線位址必須一致。不要為了避開本機故障，就將控制介面直接暴露在 0.0.0.0。

第三步：備份使用者資料，隔離損毀的設定檔

如果故障剛好發生在匯入訂閱、修改 YAML 或升級之後，應優先檢查設定檔與本機狀態。解除安裝程式通常會保留使用者資料，因此「解除安裝再安裝」未必會改變啟動時讀取的內容。正確做法是先備份，再讓程式以新的資料目錄啟動。

先找出資料夾，不要憑軟體名稱猜路徑

若能開啟介面，請優先使用「設定」中的設定目錄或記錄目錄入口；不同發行版的名稱可能是「設定目錄」、「開啟設定目錄」或「應用程式目錄」。若無法進入，請檢查下列系統位置中的應用程式專屬資料夾，並依資料夾修改時間、記錄與應用程式識別資訊確認歸屬。

• Windows：在檔案總管的網址列分別輸入 %APPDATA% 與 %LOCALAPPDATA%。設定檔與 WebView 快取可能分開儲存。
• macOS：在 Finder 選擇「前往」→「前往檔案夾」，檢查 ~/Library/Application Support/ 下的對應應用程式資料夾。
• Linux：檢查 ${XDG_CONFIG_HOME:-$HOME/.config} 與 ${XDG_DATA_HOME:-$HOME/.local/share} 下的應用程式資料夾；若自訂了 XDG 環境變數，請以實際路徑為準。

透過重新命名建立全新環境

1. 結束用戶端與已確認屬於它的背景程序，必要時先停止相應服務。
2. 將整個應用程式設定資料夾複製到另一個備份位置。備份內容可能包含訂閱網址、節點憑證與控制介面金鑰，請限制存取權限。
3. 將原設定資料夾重新命名，加上 .backup-20261017 等容易辨識的後綴。不要刪除整個 AppData、Library 或 .config。
4. 啟動用戶端，暫時不要匯入舊設定，也不要啟用 TUN，確認主視窗能否穩定開啟。
5. 若新環境運作正常，請先匯入一份確認可用的訂閱，再逐項恢復規則覆寫、指令碼和其他設定。

記錄中出現 yaml: line、unmarshal 或策略名稱不存在等錯誤時，請檢查相應行、欄位型別與參照關係。YAML 縮排使用空格，同一層級的欄位應對齊；策略群組參照的節點或群組名稱必須確實存在。用戶端外殼能開啟，不代表目前的核心支援舊設定中的所有欄位。

第四步：排除殘留服務模式與 TUN 權限問題

服務模式用來讓背景元件以所需權限執行；TUN 則透過虛擬網卡接管流量。兩者相關，但不是同一個開關。若系統代理正常，只有啟用 TUN 才失敗，應優先檢查服務狀態、權限與虛擬網卡，而不是重新安裝 WebView2。

先恢復一般代理，再處理服務

1. 若能進入設定，請先關閉 TUN，再使用用戶端提供的服務模式管理入口停止或修復服務。實際按鈕名稱請以目前版本顯示為準。
2. 在 Windows 按下 Win + R，輸入 services.msc。在候選服務的「內容」中核對執行檔路徑，確認是否指向舊的安裝位置。
3. 若升級後仍有舊服務，請優先使用原用戶端或相應安裝程式提供的解除安裝、修復流程，再由目前的用戶端安裝服務。
4. 重新啟動後，先在關閉 TUN 的狀態下驗證介面與核心，再另外測試 TUN。

不要只憑相似的顯示名稱就執行 sc delete，也不要批次刪除虛擬網卡。舊服務路徑失效、服務無法啟動與路由衝突需要分別處理；系統管理員權限只能解決部分權限問題，無法修復損毀的設定檔或被占用的連接埠。

macOS 的背景輔助元件、Linux 的 systemd 服務也應核對程式路徑。若服務檔案屬於另一個仍在使用的用戶端，請勿順手清除。公司配發的裝置也可能受到網路政策限制，請先確認裝置管理規範。

第五步：檢查安全軟體的攔截記錄，不要直接全面關閉防護

「昨天正常，今天突然無法開啟」可能與程式更新、核心檔案遭隔離或安全政策變更有關。Windows 請開啟「Windows 安全性」→「病毒與威脅防護」→「保護歷程記錄」，依閃退時間查看是否涉及用戶端、核心或輔助服務檔案。

• 記下遭處理檔案的完整路徑、偵測名稱與時間。桌面圖示仍在，不能證明程式檔案完整。
• 先確認安裝檔來自該專案的正式發布管道，查看發布說明及系統提供的簽章資訊；不要還原來源不明的執行檔。
• 確認是誤判後，再依組織政策提出申訴或設定範圍最小的例外；不要將整個下載資料夾或使用者資料夾加入排除清單。
• 受控資料夾存取若阻止寫入，也可能導致應用程式無法儲存狀態；只授權給已確認可信的特定程式。

macOS 若顯示「無法驗證開發者」或「App 已損壞」，請先重新下載符合處理器架構的正式安裝檔，並查看系統安全性提示。不要直接執行批次移除隔離屬性的指令。Linux 則應一併檢查檔案執行權限、系統記錄與安裝套件相依性錯誤。

各平台清除重裝：保留線索，分階段還原

若上述檢查仍無法找出原因，再進行清除重裝。請先保存崩潰記錄、版本資訊與使用者資料備份，並關閉系統代理，避免解除安裝後瀏覽器仍連線至已不存在的本機連接埠。請安裝目前系統支援的維護版本，不要隨意下載較舊的安裝檔。

Windows

1. 正常結束用戶端，停止已確認的服務，再前往「設定」→「應用程式」→「已安裝的應用程式」，解除安裝相應程式。
2. 將已確認屬於該應用程式的殘留設定資料夾重新命名保留；不要刪除共用的 WebView2 Runtime。
3. 依系統架構重新安裝。若出現檔案正在使用或服務仍在執行的提示，請先處理殘留程序，必要時重新啟動系統。
4. 首次啟動時不要還原舊設定。介面正常後，依序測試訂閱、系統代理、服務模式，最後再測試 TUN。

macOS

1. 從選單列結束用戶端；依用戶端支援的流程解除安裝其輔助服務，再移除「應用程式」中的舊版 App。
2. 備份並重新命名相應的 Application Support 資料夾。不要清空整個 Library。
3. 從蘋果選單的「關於這台 Mac」確認裝置使用 Apple 晶片還是 Intel 處理器，再選擇相應的安裝檔。
4. 若仍會崩潰，請在「主控台」中查看崩潰報告，並留意 ~/Library/Logs/DiagnosticReports/ 內發生時間相符的報告。

Linux

1. 確認安裝方式是 DEB、RPM 或其他發行版套件格式；先使用原本的套件管理方式解除安裝，避免同時保留多個來源的桌面捷徑。
2. 從終端機啟動實際的執行檔並保存標準錯誤輸出。檢查缺少的程式庫、顯示工作階段與權限錯誤，再依發行版的要求安裝相依套件。
3. 備份並重新命名相應的 XDG 資料目錄後再重新安裝。WebKitGTK 相依套件名稱會因發行版與組建而異，不要跨系統照抄舊的相依套件清單。
4. 一般桌面視窗穩定後，再設定服務與 TUN。不要為了開啟視窗，長期以 root 身分執行整個圖形介面用戶端。

修復後驗證：每次只加回一項設定

修復完成不只是視窗能開啟，還要確認核心持續執行、記錄不再重複報錯，而且結束用戶端後系統網路能恢復。建議依下列順序驗證；哪一步再次出現故障，就回到該環節檢查，而不是重新從頭解除安裝。

1. 空白啟動：不匯入舊資料，連續啟動並結束兩次，確認視窗、系統匣與背景程序的行為一致。
2. 單一設定檔：匯入確認可用的訂閱，檢查是否已選取該設定檔，以及核心是否成功載入。
3. 系統代理：確認實際監聽連接埠，啟用系統代理後瀏覽平常使用的網站，並查看連線記錄是否出現相關請求。
4. 自訂規則：逐項還原覆寫、指令碼與規則集。問題再次發生時，保留本次新增的項目與錯誤行。
5. TUN 與服務：最後才啟用，並檢查是否與其他 VPN、虛擬網卡或企業網路軟體衝突。

提交問題回報時，請附上作業系統版本與架構、用戶端和核心版本、安裝方式、故障發生時間、觸發步驟、空白設定是否能重現，以及相關記錄。請移除訂閱連結、節點位址、密碼、控制金鑰與個人路徑中的敏感資訊。能清楚說明「空白設定可啟動，還原某項覆寫後失敗」，通常比只寫「一開啟就閃退」更容易找出原因。