本文目錄
確認故障發生在下載成功、核心拒絕之後
本文處理的是一個範圍明確的 Clash Party 2.0 問題：原來的 Profile 可以使用，重新整理遠端訂閱後卻提示設定驗證失敗，熱重載或重啟核心也隨之失敗。官方 issue #2047 記錄的不是下載超時，而是新檔案已下載、YAML 也能解析，最終設定卻無法透過 Mihomo 驗證。
如果訂閱位址回傳 401、403、HTML 頁面、空內容或 Invalid YAML，故障發生得更早，應先按訂閱回應和 YAML 語法檢查。只有下載成功、Profile 已被改寫，而 Mihomo 隨後拒絕載入的情況，才適合繼續使用本文。
按最後一條有效錯誤分流
| 看到的結果 | 故障階段 | 處理入口 |
|---|---|---|
| 401、403、超時或回傳網頁 | 訂閱請求沒有取得設定 | 檢查連結、授權、網路和提供方狀態 |
| Invalid YAML、縮進或引號錯誤 | 檔案尚未透過 YAML 解析 | 修復格式，不繼續覆蓋現有 Profile |
| YAML 可讀，但出現 proxy group not found 等錯誤 | Mihomo 語義驗證失敗 | 核對節點、策略群組、規則和覆寫之間的引用 |
| 更新成功，只有某個節點連線失敗 | 設定已載入，問題在節點或協議 | 轉向節點、TLS、UDP 或網路檢查 |
還能聯網時，先保住正在執行的舊設定
設定熱重載失敗後，正在執行的 Mihomo 可能暫時仍使用上一份可用設定。此時不要急著重啟核心、退出應用或再次重新整理訂閱；這些動作可能讓尚能工作的舊執行狀態消失，卻不會自動修好已經寫入磁碟的新檔案。
暫停按一下訂閱卡片的重新整理按鈕；若這份 Profile 設定了自動更新，也先臨時停用並記下原間隔。隨後從已有備份中找出上一份可用 Profile，或讓訂閱提供方先修復上游設定。不要把唯一備份直接作為試驗檔案。
保留恢復機會
固定目前執行狀態
不要切換 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 版本決定，不能用不同核心代替驗收。
把新訂閱當作候選檔案單獨驗證
修復時先把新訂閱儲存為臨時副本，不要覆蓋目前 Profile，也不要把含 token 的連結提交給線上轉換網站。逐一確認每條規則的目標、每個策略群組成員和所有覆寫引用都存在，再用 Clash Party 實際選擇的 Mihomo 核心測試這份最終候選。
熟悉命令列的使用者可以對臨時副本執行 Mihomo 的測試模式。命令成功退出只表示該候選能被這個核心解析和初始化；它不能證明節點可連線，也不能替代後面的實際請求。不要對唯一設定原件執行就地改寫。
從候選檔案到可匯入設定
保留遠端原件
把本次下載內容放在臨時目錄，另存一份脫敏副本用於比對，不把訂閱 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.1 已正式收錄儲存前驗證
Clash Party v2.0.1 已於 2026 年 8 月 11 日發布，官方發布說明明確列出「遠端訂閱更新前未驗證設定，異常內容可能覆蓋原有可用訂閱」的修復。v2.0.0 仍不具備這項保護；目前穩定版已更新至 v2.0.2，正在使用舊版的使用者應先備份可用 Profile，再從官方 Release 升級。
v2.0.1 會先把遠端訂閱當作候選，疊加受控設定、規則和覆寫，再呼叫所選 Mihomo 的 -t 模式驗證臨時檔案。驗證失敗時不替換已儲存的 Profile，也不重載核心；臨時檔案隨後清理。這個保護只約束後續更新，不會自動找回升級前已經被覆蓋的舊設定。
目前可選做法
| 選擇 | 適合誰 | 邊界 |
|---|---|---|
| 升級到 v2.0.1 或更高穩定版 | 希望獲得更新前驗證的使用者 | 目前穩定版為 v2.0.2；先備份 Profile，再用失敗候選確認舊設定不會被改寫 |
| 暫時保留 v2.0.0 | 目前無法安排升級的使用者 | 暫停自動更新並手動驗證候選；舊版仍可能覆蓋可用 Profile |
| 降級舊版應用 | 僅用於其他明確版本回歸 | 不能恢復已經被覆蓋的 Profile，也不能保證避開同一更新路徑 |
用失敗候選和有效候選完成驗收
升級到 v2.0.1 或更高穩定版（目前為 v2.0.2）後，應在備份環境做兩次更新。第一次使用已脫敏的無效候選，確認 Clash Party 回傳驗證錯誤，但舊 Profile 內容、目前核心執行和節點連線都不變化；第二次換成已驗證的有效候選，確認儲存、重載和實際存取同時成功。
只看到「更新完成」提示還不夠。真正的閉環是無效更新不會破壞上一份可用設定，有效更新可以生效，退出並重新啟動 Clash Party 後仍能選擇策略群組、產生連線記錄，並且系統代理或 TUN 能正常關閉和恢復。
v2.0.1 更新保護驗證清單
- Clash Party 已升級到官方 v2.0.1 或明確包含該修復的後續穩定版
- 無效候選會顯示 Mihomo 的具體驗證錯誤
- 無效候選不會改寫已儲存的上一份可用 Profile
- 驗證失敗時，目前 Mihomo 不會被重載或停止
- 有效候選可以儲存，並能看到預期的節點與策略群組
- 實際網頁請求出現在連線記錄，規則與出口符合預期
- 退出並重開應用後仍可聯網，系統代理和 TUN 可以正常恢復
- 重新啟用自動更新前已經儲存新的可用備份