本文目錄
更新訂閱後出現驗證錯誤，目前連線卻仍可用，這時急著重新啟動可能連最後可用的執行狀態也失去。應保留原始資料與錯誤，把新內容另存為候選檔案檢查，再還原可用設定。應用程式升級能保護後續更新，但不會自動找回先前已被覆蓋的檔案。
訂閱已下載，Mihomo 卻拒絕新設定
記錄 Clash Party 2.0 中原本可用的 Profile、更新後的最終設定與完整驗證錯誤。官方 issue #2047 的情況是新檔案已下載、YAML 能解析，卻被 Mihomo 拒絕，接著無法熱重載或重新啟動；不能將它視為下載逾時。
如果訂閱位址返回 401、403、HTML 頁面、空內容或 Invalid YAML，故障發生得更早，應先按訂閱回應和 YAML 語法檢查。只有下載成功、Profile 已被改寫，而 Mihomo 隨後拒絕載入的情況，才需要核對更新後的最終設定。
還能聯網時，保留正在執行的設定
設定熱重載失敗後，正在執行的 Mihomo 可能暫時仍使用上一份可用設定。此時不要急著重啟核心、退出應用或再次重新整理訂閱；這些動作可能讓尚能工作的舊執行狀態消失，卻不會自動修好已經寫入磁碟的新檔案。
保留恢復機會
固定目前執行狀態
不要切換 Profile、重啟核心或重新啟動 Clash Party，先確認目前網頁是否還能透過原節點存取。
儲存錯誤與版本資訊
複製驗證錯誤，記錄 Clash Party、Mihomo、Profile 和更新發生時間；不要匯出含金鑰的完整日誌。
複製可用備份
把最近一次確認可用的 Profile 複製到單獨目錄，並保留原檔案不動；沒有備份時先向提供方索取修正後的設定。
停止繼續覆蓋
暫停手動重新整理和自動更新，記下原更新間隔。候選檔案通過所選核心完整驗證前，不把下載內容貼上回目前 Profile；不要把唯一備份當試驗檔案。
YAML 能開啟，不代表 Mihomo 能執行
YAML 解析器只判斷縮排、清單和鍵值結構是否成立，不會證明每個策略群組引用都存在。下面的示例在語法上有效，但「手动选择」引用了一個沒有定義的策略群組；Mihomo 載入時仍會拒絕它。
Clash Party 還會把遠端訂閱與全域覆寫、單個 Profile 覆寫、規則和受控設定組合成最終執行設定。遠端檔案單獨看起來正常，也可能在合併後產生重名、缺失引用或不受支援的欄位，因此必須驗證最終候選，而不是只把 YAML 開啟看一眼。
proxies:
- name: 节点 A
type: socks5
server: 127.0.0.1
port: 1080
proxy-groups:
- name: 手动选择
type: select
proxies:
- 不存在的策略组
rules:
- MATCH,手动选择錯誤指出某個 proxy group 不存在
檢查該名稱是否真的出現在 proxies 或 proxy-groups，並核對空格、大小寫和全角符號。
關閉某個覆寫後驗證通過
問題在合併結果；修正覆寫中的舊組名或欄位，不要修改無關節點。
原始訂閱與所有覆寫組合後仍失敗
把脫敏後的準確錯誤交給訂閱提供方，要求修復上游產生設定。
同一檔案用另一個核心版本通過
保留兩個版本與完整錯誤，按實際要執行的 Mihomo 版本決定，不能用不同核心代替驗收。
根據最後一條有效錯誤選擇處理方式
| 看到的結果 | 故障階段 | 處理入口 |
|---|---|---|
| 401、403、超時或回傳網頁 | 訂閱請求沒有取得設定 | 檢查連結、授權、網路和提供方狀態 |
| Invalid YAML、縮排或引號錯誤 | 檔案尚未通過 YAML 解析 | 修復格式，不繼續覆蓋現有 Profile |
| YAML 可讀，但出現 proxy group not found 等錯誤 | Mihomo 語義驗證失敗 | 核對節點、策略群組、規則和覆寫之間的引用 |
| 更新成功，只有某個節點連線失敗 | 設定已載入，問題在節點或協議 | 轉向節點、TLS、UDP 或網路檢查 |
把新訂閱當作候選檔案單獨驗證
候選設定儲存在獨立的臨時位置，不覆蓋目前 Profile，也不把含 token 的連結交給線上轉換網站。
熟悉命令列的使用者可以對臨時副本執行 Mihomo 的測試模式。命令成功退出只表示該候選能被這個核心解析和初始化；它不能證明節點可連線，也不能替代後面的實際請求。不要對唯一設定原件執行就地改寫。
命令中的 mihomo 必須是應用程式實際選擇的可執行檔，不能用另一份同名程式代替。candidate.yaml 應指向套用實際覆寫後的暫存副本；無法確認核心或候選檔位置時，先不要執行測試。
從候選檔案到可匯入設定
保留遠端原件
把本次下載內容放在臨時目錄，另存一份脫敏副本用於比對，不把訂閱 URL 寫進命令歷史或工單。
核對引用關係
從驗證錯誤點名的組開始，檢查 proxies、proxy-groups、rules 與 rule-providers，修復不存在或被改名的目標。
疊加實際覆寫
把全域覆寫和該 Profile 的覆寫納入檢查；如果只有合併後失敗，應修覆寫而不是反覆下載同一訂閱。
使用所選核心測試
對臨時最終設定執行測試模式，儲存退出碼和錯誤；只有退出成功才進入匯入步驟。
mihomo -t -f candidate.yaml- 遠端訂閱候選只寫入臨時檔案，不覆蓋目前 Profile
- 合併規則與覆寫產生 Clash Party 實際要執行的最終設定
- 所選 Mihomo -t檢查組引用、欄位與核心相容性
- 成功後再儲存失敗則清理臨時檔案並保留上一份可用設定
PR #2048 把儲存動作移到 Mihomo 驗證之後；v2.0.0 尚未包含這項保護，v2.0.1 已正式收錄。升級不會自動恢復此前被覆蓋的 Profile。
核心無法啟動時，恢復上一份可用 Profile
如果核心已經停止，先關閉系統代理和 TUN，確認作業系統能夠直連，避免所有下載繼續指向失效的本機連接埠。然後把之前備份的可用設定作為一個新 Profile 匯入，保留損壞的 Profile 只用於離線比對，不要讓它再次成為目前設定。
沒有備份時，不要靠刪除整個 Clash Party 資料目錄碰運氣。讓訂閱提供方修復設定，先在臨時位置完成語義驗證，再以新名稱匯入；這樣仍能保留原來的覆寫、錯誤證據和還原線索。
按可還原順序恢復
恢復系統直連
關閉系統代理與 TUN，確認瀏覽器不再連線失效的本機代理連接埠；記下原開關，恢復後再逐項開啟。
匯入上一份可用副本
用新名稱建立 Profile，先不刪除故障設定，也不啟用自動更新。
啟動核心並測試一個節點
選擇已知可用節點，開啟一個普通網頁，再從連線記錄確認請求確實進入新 Profile。
驗證後恢復自動更新
只有一次手動更新、重載和應用重啟都通過後，才恢復原來的更新間隔。重新啟用前儲存新的可用備份。
儲存前驗證怎樣保護設定？升級為什麼要選 v2.0.3 或後續穩定版？
Clash Party v2.0.1 已於 2026 年 8 月 11 日發布，官方發布說明明確列出“遠端訂閱更新前未驗證設定，異常內容可能覆蓋原有可用訂閱”的修復。v2.0.0 仍不具備這項保護。
截至 2026 年 9 月 23 日，官方最新穩定版為 v2.0.3，且修復了惡意 rule-providers 設定可能執行任意命令的問題。正在使用舊版的使用者應先備份可用 Profile，再從官方 Release 升級。
v2.0.1 會先把遠端訂閱當作候選，疊加受控設定、規則和覆寫，再呼叫所選 Mihomo 的 -t 模式驗證臨時檔案。驗證失敗時不替換已儲存的 Profile，也不重載核心；臨時檔案隨後清理。這個保護只約束後續更新，不會自動找回升級前已經被覆蓋的舊設定。
目前可選做法
| 選擇 | 適合誰 | 邊界 |
|---|---|---|
| 升級到 v2.0.3 或後續穩定版 | 希望獲得更新前驗證的使用者 | 先備份 Profile，再用失敗候選確認舊設定不會被改寫；v2.0.3 同時修復了 rule-providers 安全問題 |
| 暫時無法升級 | 需要先儲存現有 Profile 的使用者 | 暫停自動更新並手動驗證候選；舊版仍可能覆蓋可用 Profile，也不含 v2.0.3 的安全修復，應盡快升級 |
| 降級舊版應用 | 不建議作為恢復設定的方法 | 既不能恢復已經被覆蓋的 Profile，也會失去 v2.0.3 的安全修復 |
錯誤訂閱會覆蓋舊設定嗎？正常訂閱能否更新？
升級到官方 v2.0.3 或後續穩定版後，應在備份環境做兩次更新。第一次使用已脫敏的無效候選，確認 Clash Party 返回驗證錯誤，但舊 Profile 內容、目前核心執行和節點連線都不變化；第二次換成已驗證的有效候選，確認儲存、重載和實際存取同時成功。
只看到「更新完成」提示還不夠。無效更新應保留上一份可用設定，有效更新應能正常生效。結束並重新啟動 Clash Party 後，仍應能選擇策略群組、產生連線記錄，系統代理或 TUN 也能正常關閉和恢復。連線記錄中的規則和出口應符合預期。