連線疑難排解 · Clash 技術部落格

Clash Verge Rev 啟動卡兩分鐘：Windows 服務修復

Windows 開機後 Clash Verge Rev 卡住約兩分鐘？先查詢服務啟動類型與狀態，再依 v2.5.8 修復說明恢復自動啟動，驗證重新啟動、TUN 與實際請求，並保留還原方式。

閱讀正文回到部落格
  • Clash Verge Rev
  • Windows
  • v2.5.8
  • 系統服務
  • 啟動等待
本文目錄
文章作者
Clash 官網
發布日期
預計閱讀
約 8 分鐘

Windows 開機後開啟 Clash Verge Rev，介面卡住約兩分鐘，接著出現服務降級提示；等待期間切換系統代理或更新訂閱，又顯示核心尚未執行。先查系統服務的啟動類型，不急著換節點或反覆重裝。

先區分啟動等待與一般連線失敗

本文適用於 Windows 10/11 上的 Clash Verge Rev 服務啟動疑難排解。官方問題紀錄描述了服務被改為手動後等待，再退回一般核心模式的情況；v2.5.8 正式發行紀錄已列出修正與一鍵修復功能。約兩分鐘是特定故障的線索，並非所有啟動緩慢的共同原因。

依症狀決定下一步

看到的情況先檢查什麼
開機後等待很久，接著提示服務降級檢查 clash_verge_service 的啟動類型、目前狀態與應用程式日誌。
服務不存在，或路徑指向另一份安裝改查服務安裝與版本相容性，不能把自動啟動命令當成安裝服務。
服務正常，只有節點測速或網站連線失敗改查節點、DNS 與規則，不重複修改服務啟動類型。
日誌明確指出核心檔案未通過安全檢查依對應的安全檢查指南處理；修改啟動類型無法修復檔案或權限問題。

系統服務自動啟動與應用程式開機啟動不同

Clash Verge Rev 的系統服務會以較高權限協助啟動核心，讓應用程式主介面維持一般權限，也能使用 TUN。應用程式是否在開機時顯示視窗，與 Windows 是否自動啟動該服務，是兩項設定；只開啟應用程式自動啟動，無法證明服務類型正確。

Windows 的自動啟動、手動啟動與已停用並不相同。服務設為手動時，不會只因開機就自動就緒；已停用時則無法直接啟動。先核對實際狀態，不根據應用程式圖示或單次能連上網路，就推斷服務已恢復。

官方問題中的維護者指出，開機最佳化工具可能修改服務類型。本文不據此認定所有電腦都由同一種軟體造成，也不保證升級能阻止其他工具再次改寫設定。

v2.5.8 正式組建的專用提示另有條件：服務已停止，且啟動類型不是自動。服務已在執行時，即使類型仍為手動，也不能據此認定會立即出現該提示；下次開機能否自動就緒，仍須另外驗證。

先以唯讀方式記錄服務設定與執行狀態

保留修復前的對照資料

  1. 記錄版本與日誌

    記下完整用戶端版本、Windows 版本、啟動等待的大致時間與最後提示。保留從啟動開始的應用程式日誌，不只擷取最後一行；可從應用程式設定中的「日誌目錄」入口開啟。

  2. 查詢實際服務

    在命令提示字元或 PowerShell 執行下列兩個唯讀命令。使用 sc.exe 全名，避免同名命令造成混淆；先儲存輸出，再決定是否修改。

  3. 核對服務身分與狀態

    查看 START_TYPE、BINARY_PATH_NAME、STATE 與 PID。確認服務名稱為 clash_verge_service，路徑屬於目前可信任的安裝；手動類型通常顯示 DEMAND_START，自動類型顯示 AUTO_START。服務正在執行，不代表下次開機也會自動啟動。

Windows：唯讀查詢
sc.exe qc clash_verge_service
sc.exe queryex clash_verge_service

若回傳服務不存在、存取被拒，或路徑與目前安裝不符，先保留完整錯誤。缺少服務時，需要正確的安裝或修復流程；權限受組織管理時，使用既有的管理員流程，不憑猜測修改服務路徑或刪除服務。

確認類型被更改後，再恢復自動啟動

先備份設定，確認已安裝正式版 v2.5.8 及相符的目前服務元件。出現「修復服務」提示時，主要操作「重新安裝服務」會重裝服務，再重新啟動核心；完成後仍須核對實際狀態。舊版或安全狀態不明的服務，應先透過正式管道處理，不直接啟用。

下列手動步驟只適用於已確認與 v2.5.8 相符的可信任服務，且允許恢復自動啟動的情況。安裝來源與目錄看起來正確，無法取代服務版本與安全狀態的確認；不確定時，先使用應用程式的服務重裝流程。

手動恢復的順序

  1. 先結束目前的用戶端

    先記錄系統代理、TUN 開關原值，以及原本可用的網路方式，再儲存設定，暫時關閉這些開關並正常結束應用程式。修復可能中斷網路，請安排在可中斷的時段；不要同時執行多個版本，反覆安裝服務。

  2. 以管理員身分修改類型

    開啟管理員命令提示字元，只執行下方第一個命令。start= 後必須有空格；此命令會修改服務啟動類型，不會立即啟動服務。

  3. 啟動服務後重新開啟應用程式

    第一個命令成功後，再執行第二個，並以唯讀查詢確認狀態。若服務已在執行，先核對狀態，不因這項提示反覆修改；接著以一般方式開啟用戶端。

Windows：僅在確認後修復
sc.exe config clash_verge_service start= auto
sc.exe start clash_verge_service

任何一步失敗，都應停在該處，保留原始錯誤與設定輸出。不要連帶修改 binpath、服務帳戶、權限或關閉安全軟體；服務安全檢查、殘留核心與新舊通訊協定不相容，各有對應的判斷流程。

重新開啟與重新開機後都驗證，才算修好

修復後的驗證清單

  • sc.exe qc 的 START_TYPE 符合預期，BINARY_PATH_NAME 仍是修復前核對過的可信任路徑。
  • sc.exe queryex 顯示服務已在執行，重新開啟用戶端後，沒有本文所述的長時間等待或服務降級提示。
  • 依需求恢復系統代理與 TUN 原值，分別檢查應用程式日誌與實際 HTTPS 請求，不只看節點延遲或開關顏色。
  • 在適當時機重新啟動 Windows，再查詢類型與狀態，確認並非只有這次手動啟動後暫時可用。
  • 若重新開機後又變成手動或已停用，保留 Service Control Manager 相關事件與時間，找出是哪項原則或工具改寫，不要每天重裝。

需要檢查開機最佳化設定時，只處理與該服務明確相關的規則，並保留原設定。組織設備應使用管理員允許的方式；應用程式自動啟動選項、服務啟動類型與是否主動啟用 TUN，要分別驗證，不能互相取代。

仍失敗時還原，並排查其他故障

若需撤銷手動變更，依事前儲存的 START_TYPE 恢復原類型。原值為手動時對應 demand，已停用時對應 disabled；使用相同的 sc.exe config 語法，只替換 start= 後的類型。修改啟動類型不會自動停止已在執行的服務；恢復這些類型，可能再次使服務無法隨開機就緒。

服務可用前，先依記錄恢復原本可用的網路方式，不把 TUN 視為已經恢復。需要停用或重裝服務時，先儲存工作、結束用戶端，再依受支援流程處理，不以刪除服務或修改執行檔路徑來試錯。

若升級後發生相容性問題，保留設定備份與目前日誌，再依專案支援的方式恢復對應版本與服務元件；不要讓新舊版本共用僅有的資料目錄。回復版本不會自動還原外部工具的開機原則，也不要回復到已知安全問題尚未修正的組建。

服務已自動啟動卻仍失敗時，記錄是否存在舊服務或殘留核心、實際路徑與完整錯誤，改查安全檢查或核心通訊指南。不要把一個自動啟動命令擴大解讀為所有服務故障的通用修復方法。

參考資料