Stash 的 Override 补规则很方便，但合并语义要看清。很多故障不是订阅坏了，而是 Override 把原有策略组替换掉了。排查时不要同时改三处，先找个可重复的失败样本，再把日志和字段对上。
##判断你是哪一种故障？
| 故障表现 | 更可能原因 | 现场先看 |
|---|---|---|
| 启用 Override 后策略组少一半 | #!replace 覆盖 proxy-groups | Override 文件开头和相关段落 |
| 规则提示 group not found | Rule 右侧组名被改掉 | 规则引用和策略组名称 |
| url-test 组为空 | include-all 未包含 provider 节点 | proxy-providers 与 filter |
| 禁用 Override 后恢复 | 覆写文件问题 | 逐段启用定位 |
如果表里有两项同时命中，处理更靠近系统入口的那一项。端口、服务、VPN 权限、DNS 监听都属于入口层；订阅、规则、策略组属于配置层。入口没通时，配置层再正确也看不出效果。
为什么不要一上来重装客户端？
重装会清掉一部分状态，也会把证据一起清掉。很多用户重装后短时间恢复，是因为旧服务、DNS 缓存或监听端口被重启释放了，并不代表根因消失。下一次更新、重启或切换网络后，问题可能原样回来。
更稳妥的办法是保留现状，做最小化测试。只开一个入口，只用一个测试域名，只改一个字段。每次改动后都记录现象，这比反复导入新配置更快。
现场定位：看哪条日志和哪个字段？
- UI 路径：Stash → Profiles → Override，逐个关闭测试。
- 日志关键词：
proxy group not found、invalid proxy group、provider not found。 - 配置字段：
proxy-groups、proxy-providers、include-all、filter。 - 文件后缀：
.stoverride，不要和完整 YAML 混用。
可以直接执行或在 UI 里完成这些检查：
在 Stash 里复制生效后的配置并搜索 proxy-groups
只保留一个 Override 文件重新启用
将 `#!replace` 改为普通合并后保存测试
用同一订阅新建空 Profile 作为对照日志里如果同时出现端口占用和 DNS 失败，处理端口。DNS 组件起不来时，后面的规则命中、策略选择和连接测速都会失真。
字段和客户端兼容表
| 字段或组件 | 适用客户端/平台 | 作用 | 兼容提醒 |
|---|---|---|---|
.stoverride | Stash | 覆写配置 | 合并语义要看文档 |
#!replace | Stash Override | 替换整个字段 | 容易误删原组 |
proxy-groups | Clash 系 | 策略组列表 | Rule 依赖名称 |
proxy-providers | Clash 系 | 远程节点来源 | provider 名称要一致 |
include-all | Stash | 自动包含节点 | 筛选条件过严会为空 |
兼容表的用法不是照抄字段，而是确认「谁负责入口，谁负责规则，谁负责 DNS」。一个字段在桌面客户端里只是本机设置，放到 OpenWrt 上就可能影响整段局域网。
修复步骤怎么排？
- 禁用全部 Override，确认原订阅策略组完整。
- 只启用一个覆写文件，观察策略组数量变化。
- 检查
#!replace是否作用在proxy-groups顶层。 - 把 Rule 右侧组名改为实际存在的策略组名称。
- 确认 provider 和 include-all 能抓到节点后再补规则。
如果你维护多台设备，最好先拿一台测试机做验证。确认核心链路恢复后，再把同一套配置同步到手机、平板或软路由。多端共用订阅时，可以准备一份兼容 Clash / Singbox / V2Ray 的订阅作为基线输入，但排错仍要从本机日志开始。
哪些情况不该继续改配置？
出现下面几种情况，先停手：第一，日志已经提示文件缺失或权限不足，却还在改规则；第二，同一台设备上同时开了两个 DNS 接管组件；第三，服务重启后错误字符串变化很大，说明你一次改了太多变量。
还有一种常见误区是把「测速失败」当成所有问题的根因。测速只是客户端发起的一次请求，不能证明 DNS、TUN、Rewrite 或策略组都正常。要用真实 App 或浏览器请求补一次验证。
怎么验证已经恢复？
- 同一个测试域名连续打开 3 次，结果一致。
- 日志里不再出现本篇 TL;DR 提到的错误字符串。
- 连接记录进入预期策略组或出站，而不是落到兜底项。
- DNS 返回值、监听端口和 UI 状态三者能互相对应。
验证要回到最初的失败样本。不要换一个网站就宣布修好，也不要只看 UI 绿色状态。能复现同一个动作，并在日志里看到清晰命中，才算完整链路。
记录哪些证据才有用？
处理「Stash Override 合并后策略组丢失怎么处理」这类问题时，建议把证据写成一行，而不是只截一张失败截图。可记录客户端版本、系统版本、当前入口端口、DNS 监听地址、失败域名、日志关键词和最后一次改动时间。以后同一个配置换到另一台设备上，能直接判断是环境差异还是配置差异。
如果团队里有多人维护配置，变更前后最好各保留一份导出的配置。不要只说「我改了 DNS」或「我开了 TUN」，而是写清具体字段，例如端口从 7890 改到 7897，Fake-IP 过滤新增了 *.lan，或 Script 里新增了一个策略组。这样的记录能减少重复试错，也方便回滚。