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

Clash Verge Rev SSH 私鑰出錯：服務模式修復

Clash Verge Rev 使用 SSH 私鑰檔後，服務核心或 TUN 無法啟動？先核對第一筆路徑錯誤、應用程式設定目錄與 v2.5.10 修復，保留金鑰及設定，再用原節點驗證是否恢復。

閱讀正文回到部落格
  • Clash Verge Rev
  • SSH
  • private-key
  • 服務模式
  • v2.5.10
本文目錄
文章作者
Clash 官方
發布日期
預計閱讀
約 8 分鐘

設定加入 SSH 私鑰檔後，啟用服務模式或 TUN 卻顯示核心啟動失敗。先查看最早出現的檔案路徑錯誤，不要把所有啟動失敗都歸因於權限不足。

加入 SSH 私鑰檔後，為什麼核心啟動不了？

官方 issue #8445 記錄了 Windows 11、Clash Verge Rev v2.5.8 使用 SSH 私鑰檔後無法開啟 TUN 的情況。相對路徑找不到檔案，改成絕對路徑又受到 SAFE_PATHS 限制；後續的 code 1006 是核心尚未就緒時顯示的外層錯誤。

官方 v2.5.10 已納入服務模式讀取 SSH 私鑰檔的修復。本文處理的是將該檔案交給服務核心時的問題，不保證能修復所有 TUN 故障，也不把單一 Windows 回報寫成三種系統都已實測。

從第一筆錯誤判斷是否適用

實際情況接著檢查什麼
設定含 type: ssh 及檔案形式的 private-key，接著出現路徑或 SAFE_PATHS 錯誤繼續核對檔案位置與應用程式修復
只有 code 1006、IPC 尚未就緒，沒有私鑰相關錯誤保留更早的核心日誌，先找出真正原因
核心已啟動，但 SSH 驗證或主機金鑰檢查失敗檢查 SSH 憑證、伺服器與主機金鑰，這不是啟動修復的範圍
設定未使用 SSH 私鑰檔依實際的服務、網路或設定錯誤排查

相對路徑的起點不同，改成絕對路徑也未必有效

Mihomo 的 private-key 可填入私鑰內容或檔案路徑。本文只討論檔案路徑；不要為了繞過路徑錯誤，將完整私鑰貼進訂閱、公開設定或回報截圖。

服務核心有獨立的執行目錄，不能假定它能直接讀取應用程式目錄內的相對路徑檔案。v2.5.10 會將符合條件的本機私鑰暫存至服務執行目錄，並改寫交給服務的設定，使用者不必手動將檔案放進服務目錄。

這項修復仍有條件：檔案必須確實存在，解析後的實際位置仍須位於應用程式執行設定的父目錄內。相對路徑從該父目錄計算；絕對路徑也受同樣限制，不能據此宣稱磁碟上的任何檔案都能讀取。

頂層 proxies，以及 proxy-providers 的 payload 內的 SSH 項目會被處理；這不保證會遞迴掃描遠端 provider 檔案中的所有節點。內嵌私鑰、Windows UNC 或裝置路徑，也不屬於這次一般本機檔案暫存的範圍。

保留原設定與私鑰，再確認檔案實際位置

先保存目前的 Profile、自訂覆寫、原代理模式，以及可還原的外部副本。私鑰檔原件也要另外保留；只有設定 ZIP，不代表已包含外部 SSH 檔案。備份留在自己掌控的位置，求助時另外製作已移除敏感資料的副本。

開啟「設定 → Verge進階設定 → 配置目錄」。這是應用程式設定目錄，也是執行設定檔的父目錄；不要將 profiles 子目錄當成相對路徑起點，也不要手動到服務執行目錄補檔案。

在開啟的目錄中，使用 ssh 子目錄保存可信私鑰的副本，並限制存取權限。在自行維護的 Profile 或持續套用的覆寫中填寫 private-key: 'ssh/id_ed25519'，依實際檔名調整；原私鑰保持不動，以便撤銷。

確認目標是應用程式可讀取的一般檔案，而不是指向目錄外的符號連結；不要改副檔名來冒充遺失的檔案。不要直接編輯會重新產生的執行 YAML，不將私鑰放進公開儲存庫，也不取消原有檔案保護。

更新前先記錄

  • 完整應用程式版本、作業系統，目前是否使用服務模式及 TUN。
  • 實際執行設定的父目錄、private-key 寫法與檔案位置；公開回報時隱藏使用者名稱及敏感路徑。
  • 最早的檔案或安全路徑錯誤，以及後續核心啟動錯誤出現的順序。
  • 原設定、私鑰原件，以及原本可用的節點和流量接管設定。

安裝 v2.5.10，讓應用程式重新準備服務所需檔案

修復位於 Clash Verge Rev 為服務準備執行資源的程式碼中。只更新 Mihomo、重新整理訂閱或反覆開關 TUN，都無法取代完整應用程式更新。若已使用有同項修復證據的後續正式版，也不必為了本文降回 v2.5.10。

從本文參考資料中的官方 v2.5.10 Release，依自己的系統、晶片架構與原安裝方式更新。本站這次不替換託管安裝檔，舊檔仍可下載不代表已包含這項修復。

依原安裝方式更新並重新開啟

  1. 儲存工作後正常退出應用程式

    在允許中斷網路時，記錄原設定，依應用程式支援的方式停止目前的流量接管，再從系統匣完整退出。保留設定與私鑰，不刪除資料目錄，也不手動替換服務內部檔案。

  2. 完成官方應用程式更新

    使用符合系統與架構的正式安裝檔，保留原安裝方式。若安裝或簽章檢查失敗，先處理具體錯誤，不要關閉系統安全檢查來繼續。

  3. 重新開啟，核對實際執行版本

    確認實際應用程式為 v2.5.10 或有同項修復證據的後續正式版，原 Profile 與持續套用的覆寫也都還在。路徑修改須保存至來源設定並重新啟用，再核對最終設定中的 SSH 項目。

  4. 依原需求啟動服務核心與 TUN

    維持原本需要的流量接管方式，重新啟動後查看最早的日誌。不要同時改動 DNS、節點憑證與多個開關，以免無法比較結果。

核心啟動後，還要驗證原 SSH 節點能否通訊

先確認核心已就緒，不再因私鑰路徑或 SAFE_PATHS 錯誤退出，再選取原本需要的 SSH 節點，發出一筆新的實際請求。到用戶端「連線」頁確認該請求確實經過預期的 SSH 出口，並確認實際使用成功。

核心能啟動不代表 SSH 登入成功；延遲有數值或 TUN 開關亮起，也不能單獨證明身分驗證、主機金鑰檢查與實際流量都正常。若接著出現驗證失敗，應繼續檢查 SSH 伺服器與憑證，不刪除 host-key 來取消檢查。

修復後的驗證清單

  • 實際應用程式版本已包含服務模式私鑰暫存修復，最終設定使用預期的 SSH 項目。
  • 私鑰確實位於允許的應用程式設定範圍內，重新啟動後仍能讀取。
  • 服務核心能進入就緒狀態，不再因該檔案路徑錯誤退出。
  • 新連線使用預期的 SSH 節點，實際請求完成，原本的工作仍可正常進行。
  • 恢復日常模式、原選擇與必要的流量接管設定後，再核對一次結果。

本站未在真實用戶端安裝或重現此問題。本文依據官方使用者回報、正式發布、固定版本原始碼及 SSH 設定文件；網站的翻譯、原始碼層級或瀏覽器檢查，不能取代你裝置上的實際連線驗證。

仍失敗時依第一筆錯誤回復，保留檔案保護

顯示 private key is unavailable below the config root

重新核對執行設定的父目錄、檔案是否存在、解析後的實際位置及應用程式讀取權限。目錄外檔案、指向目錄外的符號連結或遠端路徑，不在這次自動暫存的保證範圍內；不要盲目更改 SAFE_PATHS。

檔案錯誤已消失，仍出現 code 1006 或其他退出情況

保存新的第一筆核心錯誤與實際版本，依此繼續查找原因；不要只憑最後一筆 IPC 錯誤就重新安裝系統服務。

更新後無法使用應用程式或原設定

停止繼續修改，保存目前狀態。先恢復自己已確認可用的設定與節點；確實需要回復應用程式版本時，依專案支援的方式使用對應備份，避免新舊程式爭用唯一的資料目錄。

暫時無法升級時，可恢復已確認可用的非 SSH 節點或原設定，先讓工作恢復；這不表示舊服務模式的私鑰問題已修好。不要為了繞過限制開放整個磁碟的讀取權限、讓所有使用者都能寫入，或將金鑰放進服務目錄作為永久解法。

回報時提供作業系統、完整應用程式版本、服務模式、private-key 使用檔案還是內容、已移除敏感資料的目錄關係，以及第一筆錯誤。不要上傳私鑰、密碼、訂閱權杖或完整設定封裝檔。

參考資料