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 里新增了一个策略组。这样的记录能减少重复试错，也方便回滚。
相关阅读
FAQ
这个问题能靠重装客户端解决吗？
多数情况下不用重装。先保留原配置副本，按日志、端口、字段顺序定位；只有确认程序文件损坏或版本缺陷时，再考虑重新安装。
为什么配置导入成功还是会出错？
导入成功只说明文件能被读取，不代表规则、DNS、端口和系统权限都正确。很多故障发生在运行阶段，要看连接记录和核心日志。
排查时应该先改订阅还是先改本机设置？
先做本机最小化测试，再判断订阅。能用固定端口或最小配置跑通，说明客户端基础链路正常，再去检查订阅格式和规则。
可以同时打开多个类似功能提高可用性吗？
不建议。DNS 接管、透明代理、TUN、Rewrite 这类入口同时开启，排错难度会翻倍。一次只保留一个主入口更容易定位。
怎么确认问题已经修好？
用同一个域名、同一个 App、同一个端口复测，并记录日志关键词消失、连接进入预期策略组、DNS 返回值符合预期这三项。