本文目錄
以管理員身分能開啟虛擬網路卡，不代表一般使用者的服務模式已恢復。安全檢查拒絕啟動時，要知道它具體指向哪個檔案或目錄；有些情況需修正安裝位置與權限，有些只涉及特定根目錄權限判斷，不能互相套用處理方式。
提示切換到 Sidecar，為什麼普通使用者開不了 TUN？
記錄 Windows 顯示「服務核心未通過安全檢查，已切換到一般模式（Sidecar）」時的執行身分。Clash Verge Rev 此時由目前使用者啟動核心，可能仍能連線，但不再透過系統服務取得高權限；一般使用者的 Sidecar 不能使用 TUN。
服務會以系統權限執行核心，因此專案會檢查核心檔案、安裝資料夾及上層資料夾的擁有者與存取權限。如果一般帳戶能替換這些檔案或資料夾，服務就必須拒絕以高權限啟動。
專案 issue #8073 記錄了 Windows 11 上 v2.5.5 與 v2.5.6 的一個案例：一般使用者開啟 TUN 後收到拒絕提示，原始錯誤指向 C 槽根目錄；以系統管理員身分執行時則可開啟 TUN。這是單一案例，不能推論每部 Windows 裝置都有相同原因。
錯誤只指向 C 槽根目錄的 DELETE 權限時，按後文的 v2.5.7 分支處理；其他路徑、擁有者或 ACL 無法讀取的錯誤，仍須檢查對應檔案與目錄。
Sidecar、服務模式與聯網結果
| 觀察到的狀態 | 下一步 |
|---|---|
| Sidecar 執行中，系統代理仍能實際連線，但一般使用者無法使用 TUN | 暫時使用系統代理，繼續查明服務遭拒的原因 |
| 服務模式可用，但 TUN 仍沒有流量或導致斷線 | 改查 TUN 介面、DNS、規則與節點，不要修改資料夾權限 |
| Sidecar 與系統代理都無法實際連線 | 先恢復 Windows 一般網路，再檢查核心與設定錯誤 |
如何找出安全檢查實際拒絕的路徑？
官方 Windows FAQ 指出，彈出通知只有簡化說明。先在應用程式內對該通知按右鍵，將原始錯誤訊息複製到記事本；不要只憑「Sidecar」一詞猜測服務未安裝、設定錯誤，或整個 C 槽都不安全。
在錯誤訊息中尋找 core path、檔名及後續原因。兩個核心檔案同時遭拒，可能只是共用某個權限不符的上層資料夾；先記錄路徑，不要直接修改 ACL。
若 core path 指向 C 槽根目錄，表示檢查一路延伸到該磁碟的根目錄，不代表應用程式安裝在 C 槽根目錄。#8073 的預設 Program Files 安裝位置也出現過這種路徑。
一併保存實際客戶端版本、安裝位置、目前的執行身分、服務模式狀態與第一則拒絕日誌。日誌或設定可能包含訂閱憑證及本機使用者名稱，公開回報前請製作遮蔽敏感資訊的副本。
路徑位於桌面、下載資料夾、使用者資料夾或自行解壓縮的資料夾
先備份設定，再依官方預設安裝路徑重新安裝。
路徑位於 Program Files 或其上層資料夾
檢查該資料夾及上層資料夾的擁有者與繼承權限，請系統管理員協助恢復正常權限。
路徑指向 C 槽根目錄，且只顯示 dangerous=0x00010000
依官方 FAQ 的磁碟區根目錄特殊情況處理，不要批次修改 C 槽權限。
錯誤寫著 is owned by，或無法讀取權限
保留完整原因；這與一般帳戶可寫入造成的錯誤不同。
系統代理可臨時聯網；確需 TUN 才以管理員啟動
關閉 TUN 後，確認 Windows 普通網路可用。Sidecar 的系統代理若能開啟實際網頁，且連線記錄中能看到請求，可以暫用系統代理；發生錯誤路徑尚未確認時，不要反覆按一下安裝服務。
確實需要暫時使用 TUN 時，專案 FAQ 提供以系統管理員身分執行的方法：從系統匣完整退出應用程式，對捷徑或 clash-verge.exe 按右鍵並選擇「以系統管理員身分執行」；出現服務修復提示時選擇「繼續使用 Sidecar」，再視需要開啟 TUN。
以系統管理員身分執行只是暫時的使用方式，不會修復服務或資料夾權限；日後每次採用此方法，仍須以系統管理員身分啟動。不需要 TUN 時，改回一般使用者執行，並使用已驗證可用的系統代理。
安裝資料夾權限不符時，如何恢復服務？
若原始錯誤指向桌面、下載資料夾、使用者資料夾或自行解壓縮的位置，先透過「設定 → Verge 進階設定 → 備份設定」保存設定，再從系統匣完整退出應用程式。使用專案官方安裝套件，安裝至預設的 C:\Program Files\Clash Verge。
不要將舊資料夾的自訂權限複製到新安裝位置，也不要授予一般使用者「修改」或「完全控制」權限。若新資料夾仍遭拒絕，先確認錯誤究竟指向核心檔案、安裝資料夾，還是更上層的資料夾。
若已安裝在預設目錄，依官方 FAQ 在檔案總管開啟錯誤路徑的「內容 → 安全性 → 進階」，核對擁有者與權限項目。核心檔案及相關資料夾的擁有者應為 SYSTEM、Administrators 或 TrustedInstaller；一般帳戶不應能修改核心、替換資料夾或變更權限。
若權限繼承自上層資料夾，或裝置由組織管理，應交由系統管理員依原有政策修復；不要藉由擴大權限讓安全檢查不再出現錯誤。確認路徑安全後，前往「設定 → 服務模式」重新安裝服務；必要時先解除安裝舊服務再安裝，並核對首頁狀態。
錯誤指向 C 槽根目錄時，還需要修改權限嗎？
若原始錯誤的 core path 指向 C 槽根目錄，而且只看到 dangerous=0x00010000，官方 FAQ 將其單獨列為磁碟區根目錄的「刪除」權限情況。先不要修改 C 槽根目錄的權限。
服務儲存庫的提交 e8f5279 調整了檢查：磁碟區根目錄無法像一般資料夾那樣刪除或重新命名，因此只在磁碟區根目錄忽略這項 DELETE 權限；對其他危險寫入權限的檢查仍保留。
v2.5.7 正式版發布說明明確指出，已修復 Windows 系統磁碟根目錄「刪除」權限誤判，導致服務模式與 TUN 無法使用的問題。#8073 記錄的是 v2.5.5 與 v2.5.6 的故障情況；不能據此推論 v2.5.7 對所有目錄權限或擁有者錯誤都有效。
若確認錯誤只涉及磁碟區根目錄的 DELETE 權限，先備份設定並完整結束應用程式，再從專案 v2.5.7 官方 Release 取得符合系統架構的正式安裝套件。更新後在「設定 → 服務模式」重新安裝服務一次，複製新的原始錯誤訊息，並以一般使用者身分驗證 TUN。若仍遭拒絕，不要反覆重裝或改動整顆磁碟的權限；暫時使用前述連線方案，再依新錯誤繼續定位。
若新的錯誤還包含其他危險權限、擁有者錯誤，或無法讀取 ACL，就不能套用「只涉及 DELETE」的處理方式。請系統管理員依新錯誤指出的具體路徑檢查；不要順手移除一般讀取權限及根目錄正常的建立資料夾權限。
如何確認一般使用者的服務模式與 TUN 確實恢復？
驗證時必須回到原本會失敗的一般使用者身分。先完整退出以系統管理員身分執行的應用程式，再以一般使用者啟動，確認首頁顯示「服務模式」，且不再跳出核心安全檢查拒絕通知；只有系統管理員視窗能開啟 TUN，不算恢復。
接著使用原來的 Profile 與節點開啟 TUN，向同一個真實的 HTTPS 網站發出請求，並在連線紀錄與日誌中確認請求確實進入核心。再關閉 TUN，確認一般網路立即恢復。
最後完整結束並重新啟動一次應用程式，重複一般使用者、服務模式、TUN 和網頁請求的檢查。若重新啟動後又回到 Sidecar，表示問題在重新啟動後仍會出現，保留新的原始錯誤訊息繼續查找原因。
仍遭拒絕時，如何回復原狀並向專案回報？
若更新或重裝服務後仍遭拒絕，先關閉 TUN，完整退出應用程式，並恢復變更前可用的系統代理或 Windows 直連。若更換安裝位置後找不到 Profile，請用事前備份還原設定；不要為了消除一則提示而放寬核心檔案的寫入權限。
不要預設退回舊版服務就能解決：目前資料沒有證明舊版可處理這項拒絕。暫時需要 TUN 時，只採用專案 FAQ 的系統管理員執行方式；不需要 TUN 時，維持一般使用者身分及已驗證可用的連線方式。
向專案 issue 回報時，請附上用戶端版本、安裝路徑、一般使用者與系統管理員的結果對照、原始 core path 與 dangerous 欄位、重裝服務後的新提示，以及真實請求結果。先移除訂閱 token、節點密碼、個人路徑及其他敏感資訊。
若新錯誤變成 is owned by、無法讀取權限或另一種寫入 ACE，就按新的具體路徑繼續查，不要套用卷根目錄 DELETE 的處理；最後以一般使用者的新錯誤與實際請求結果判斷是否恢復。