Clash Verge Rev 設定遺失怎麼辦？Profile 還原與備份

本文只處理一種明確情況：Clash Verge Rev v2.5.2 原本已有訂閱、本機 Profile 或全域 Merge/Script，正常結束、關機或重新啟動後再次開啟，設定清單突然只剩少數項目，原本的覆寫設定也可能變回空白範本。

官方 issue #7577 記錄了 macOS 啟動時 32 個 Profile 檔案被刪除 30 個；issue #7804 記錄了 Fedora 正常關機後的下一次啟動刪除 20 個檔案中的 18 個，後續評論還出現 Windows 與 macOS 報告。這些記錄都指向啟動階段的孤兒檔案清理，而不是訂閱服務同時清空了所有節點。

先開啟應用程式日誌，搜尋 Removed file、Profile 文件清理完成，以及單次啟動中異常大量的檔案刪除記錄。若磁碟中的 Profile 仍在、只有代理頁面空白，應先檢查核心通訊；若檔案存在但顯示 Invalid YAML，先修正格式或欄位；若只有一個訂閱更新失敗而其他 Profile 仍在，也不要直接還原整份應用程式備份。

還原時會把備份壓縮檔中的 config.yaml、verge.yaml、profiles.yaml 與 profiles 目錄重新寫入應用程式資料目錄。請先將目前的完整目錄和 clash-verge-rev-backup 子目錄複製到其他位置。

即使目前目錄看起來已不完整，也要先保留副本。如此一來，若選錯備份，或舊設定覆蓋新變更，仍可回復至原始狀態。

一般安裝通常會將資料放在系統資料目錄下的 io.github.clash-verge-rev.clash-verge-rev 資料夾；可攜版則放在程式旁的 .config 目錄。若不確定，請以用戶端設定中的應用程式目錄入口為準，不要只憑相似的資料夾名稱刪除資料。

Clash Verge Rev v2.5.2 的本機備份位於應用資料目錄中的 clash-verge-rev-backup。自動備份檔案名可能帶有 -auto-scheduled、-auto-merge 或 -auto-script。

issue #7804 的報告者就是從三天前的 auto-script ZIP 找回全域指令碼。

官方 v2.5.2 備份實作會把 profiles 目錄、config.yaml、verge.yaml、可選 DNS 設定和 profiles.yaml 放進同一個 ZIP。

不要只因 ZIP 能開啟就直接還原：先複製一份，再確認備份壓縮檔內同時包含 profiles.yaml 與 profiles/，並選擇故障發生前且時間最近的備份。

請保持系統代理與 TUN 關閉，開啟設定中的「備份設定」，在「本機備份」下選擇「查看記錄」。找到故障前的備份後，先按「匯出」另存一份，再按「還原」並確認。還原完成後，官方介面會重新啟動應用程式。

如果 ZIP 已經移到其他位置，先使用“匯入備份”把副本加入本機備份清單，再從記錄中恢復。不要把 ZIP 直接解壓縮到正在執行的應用目錄；內建恢復會在寫入後重新載入 config、profiles 與介面設定，手動覆蓋則容易讓磁碟檔案和記憶體狀態不一致。

沒有可用 ZIP 時，不要編造 profiles.yaml 引用或隨意改隨機檔案名。先從儲存的訂閱 URL 重新匯入遠端 Profile；本機手寫設定則從故障前複製出的 profiles 檔案中逐個辨認，在新增本機 Profile 後貼上內容並讓用戶端重新產生索引關係。

全域 Merge.yaml 與 Script.js 若仍有舊副本，應先在離線副本中比較，再透過用戶端的全域擴展編輯入口恢復。只有備份中沒有舊內容時才重新編寫；不要從公開截圖反推其中可能含金鑰或內部網域的完整規則。

如果訂閱 URL 也丟失，應到原服務提供方重新取得或重置，而不是從瀏覽器歷史、公開日誌或他人的設定中拼接 token。恢復一個來源後就儲存一次狀態，避免一次性匯入所有內容後無法定位哪一步出錯。

應用重啟後先不要立刻開啟 TUN。核對 Profile 數量、名稱、類型與目前選中項，再分別開啟 Merge 和 Script，確認關鍵規則不是空模板。遠端訂閱應能手動更新，本機 Profile 應透過設定驗證。

隨後固定一條已知可用節點，僅開啟系統代理完成一次實際 HTTPS 請求，並在連線記錄中確認網域、規則和出站。最後完整退出並重新開啟一次，再核對 Profile 數量與日誌；只有第二次啟動也沒有異常刪除，恢復才算穩定。

若恢復後應用無法啟動、Profile 數量更少或新設定驗證失敗，先關閉應用，不要連續嘗試多個 ZIP。把這次恢復後的應用資料目錄另存一份，再用最初儲存的現場副本恢復到修改前狀態。

裝置必須先保持 TUN 與系統代理關閉。還原後如果用戶端仍不可用，可以暫時不啟動它，保留日誌、備份 ZIP 與目錄副本，再在官方 issue 中提交脫敏的版本、系統、刪除計數和首條錯誤。不要為修復設定而卸載虛擬網路介面卡、重置整個系統網路或刪除所有應用資料。

2026 年 9 月 2 日，維護者在 issue #7804 中確認提交 44f6f6e 已移除不可靠的清理邏輯並關閉問題。該提交標題為“preserve files until explicit deletion”，程式碼直接刪除了啟動時 cleanup_orphaned_files 的呼叫和整套自動刪除實作。

截至 2026 年 9 月 3 日，官方 Releases 中最新穩定版仍是 2026 年 7 月 19 日發布的 v2.5.2，發布說明沒有包含這項後續修復。因此不能把“issue 已關閉”寫成“v2.5.2 已修復”，也不應僅為規避風險把日常裝置切到開發建置。

穩妥做法是先完成備份和恢復，減少不必要的重複啟動，等待官方發布明確包含 44f6f6e 的穩定版。新穩定版發布後仍要保留目前備份，核對 Release，再用完整退出、重啟和實際連線做一次回歸驗證。

恢復完成後，在備份設定中開啟定時本機備份，並保留“關鍵變更時自動備份”。v2.5.2 的實作會在計劃時間以及全域 Merge/Script 變更後建立封存，自動封存最多保留 20 份。這個數量限制意味著本機目錄不是永久歷史庫。

至少再把一份已驗證 ZIP 匯出到應用資料目錄之外，或設定自己控制的 WebDAV。每次大改訂閱覆寫、遷移用戶端或升級前手動建立並匯出一份；恢復演練時只在有還原副本的前提下進行。