本文目录
刷新订阅后出现校验错误，当前连接却还在工作，这时急着重启可能把最后可用的运行状态也丢掉。应保留原数据与错误，把新内容作为候选单独检查，再恢复可用配置。应用升级能保护后续更新，但不会自动找回此前已经被覆盖的文件。
订阅已下载，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 也能正常关闭和恢复。连接记录中的规则和出口应符合预期。