外观
Clash 更新订阅后规则总被覆盖？用覆写配置保留自定义分流
很多人在 Clash 中遇到过一个很烦的问题：为了让某个网站走直连、让公司域名走指定节点，或者修正 DNS 设置，直接打开订阅配置文件加了几行内容；当订阅下一次自动更新后，刚刚修改的内容却全部不见了。
这通常不是客户端故障，而是订阅更新机制本来就会用远端的新配置替换旧配置。要长期保留个人设置，关键不在于“修改订阅”，而在于理解并使用 覆写（Override）配置、本地规则集和独立配置文件。
先弄清楚：订阅配置为什么会被覆盖
订阅链接返回的是服务端生成的一整份 Clash 配置。客户端每次点击“更新订阅”、开启定时更新，或者重新拉取远端配置时，都会下载新版内容，并覆盖本地保存的那份订阅文件。
因此，直接编辑订阅原文会有几个问题：
- 修改无法长期保留：下次更新必然可能丢失。
- 不方便排错：过一段时间后，很难区分哪些是订阅原始内容，哪些是自己临时加的内容。
- 容易破坏 YAML 格式：缩进、冒号、引号或列表层级写错，都可能导致整个配置无法加载。
- 订阅服务端调整结构后容易冲突：例如原来的代理组名称改了，你手写的规则可能指向不存在的组。
可以把订阅理解成“只读的上游配置”。虽然很多客户端允许查看甚至编辑它，但更合理的习惯是：订阅负责提供节点和基础规则，本地覆写负责保存个人偏好。
什么是覆写配置，它适合解决哪些问题
覆写配置是叠加在订阅之上的本地补丁。客户端先读取订阅，再按覆写中的内容增加、修改或替换相应字段。订阅更新时，客户端重新下载的是订阅本身，而你的覆写文件通常仍保留在本地，因此更适合长期使用。
不同 Clash 客户端对覆写功能的命名和界面位置不完全相同，常见叫法包括：
- Override、覆写、配置覆写；
- Merge、合并配置；
- Script、脚本覆写；
- Parser、订阅解析器；
- External Controller 相关的增强配置。
在支持 Clash Meta 内核的客户端中，覆写通常能处理 rules、rule-providers、dns、proxy-groups、tun 等内容。部分客户端只提供图形化覆写，部分则需要填写 YAML 或 JavaScript 脚本。开始前，应先确认当前客户端使用的内核以及其文档中的配置格式。
覆写尤其适合以下场景：
- 给 NAS、打印机、路由器管理页等局域网地址强制直连；
- 让某个域名固定走某个代理组；
- 增加个人维护的规则集；
- 修改 DNS 策略而不碰订阅原文件；
- 给代理组增加固定的自动选择、故障切换逻辑；
- 补充 TUN 模式下的排除路由。
不过，覆写也不是越多越好。只放入自己真正需要维护的差异内容，配置才容易长期管理。
最常用的需求：追加一条本地直连规则
假设你访问家中设备时使用域名 nas.home，或者公司内部有 git.example.internal 这类地址。开启全局代理或规则未覆盖时，访问可能失败、绕远路，甚至被错误地交给代理节点。
在 Clash 规则中，规则自上而下匹配，先匹配到的规则先执行。所以，想让自定义规则优先级足够高，通常要把它插入规则列表前部，而非简单追加到最后。
概念上，一条本地规则可能像这样：
rules:
- DOMAIN-SUFFIX,example.internal,DIRECT
- DOMAIN,nas.home,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve这里的含义分别是：
DOMAIN-SUFFIX：匹配某个后缀及其子域名；DOMAIN：只匹配一个完整域名；IP-CIDR：匹配一个 IP 网段；DIRECT：直接连接，不交给代理；no-resolve：对 IP 规则不额外触发域名解析，常用于减少不必要的 DNS 查询。
但要注意，示例里的 DIRECT 并不是所有订阅都一定使用的策略名称。有些配置将直连组命名为“直连”“DIRECT”或其他名字；同样，代理策略组也可能叫“节点选择”“Proxy”“🚀 节点选择”。在覆写前先查看当前配置中的实际代理组名称，避免规则引用不存在的目标。
覆写规则时最容易犯的三个错误
1. 把 rules 整段替换掉了
这是风险最大的情况。某些覆写语法中，写入 rules: 不代表“添加规则”，而是“用我的规则列表替代原列表”。结果就是订阅自带的大量分流规则全部消失，只剩下自己写的几行。
因此，要特别区分客户端提供的是：
- 追加（append）：将规则放在原列表后面；
- 前插（prepend）：将规则放在原列表前面；
- 合并（merge）：按键名或特定策略组合内容；
- 替换（replace）：完全覆盖目标字段。
对于“本地域名必须直连”这类需求，优先选“前插规则”。如果客户端没有图形化前插功能，则需要使用该客户端支持的脚本解析器或覆写语法，不能盲目复制其他软件的 YAML 示例。
2. 规则写对了，但优先级太低
例如订阅在前面已经有一条 GEOIP,CN,DIRECT、MATCH,代理组 或更宽泛的域名规则，你把自己的规则加在最后，就可能永远匹配不到。
排查时可以暂时把规则改得更明确，例如只匹配一个完整域名；随后打开客户端的连接日志或日志面板，访问目标网站，查看最终命中的规则和策略组。日志比“感觉好像没生效”更可靠。
3. 域名规则生效了，DNS 却没有按预期工作
Clash 的分流与 DNS 相互关联。对于域名请求，客户端往往要先知道访问的是哪个域名，才能按 DOMAIN 或 DOMAIN-SUFFIX 做出正确选择。如果应用直接连接 IP、系统 DNS 被其他软件接管，或者启用了不兼容的加密 DNS 设置，就可能出现“规则看起来正确，实际仍不对”的情况。
遇到这类问题，不要第一时间大改 DNS。建议按顺序确认：
- 目标应用访问的是域名还是固定 IP；
- Clash 日志中是否显示该域名；
- 命中的规则是哪一条；
- 当前是否开启 TUN 模式，以及系统代理是否被应用绕过；
- 是否有浏览器、安全软件、DNS 工具或另一款代理软件同时接管网络。
一套更稳的长期维护方法
对于普通用户，建议把个人改动分成三层管理，而不是全部塞进订阅里。
第一层：客户端界面设置
适合放不涉及 YAML 的选项，例如：
- 系统代理开关；
- 当前选择的代理模式；
- 自动更新订阅的周期；
- 启动时是否自动连接；
- 代理组中临时选用的节点。
这类设置优先在界面里完成，避免手改配置。
第二层：本地覆写
适合放长期不变、且只属于自己的网络规则，例如家庭局域网网段、公司内部域名、指定网站的策略选择，以及少量 DNS 调整。
建议为每一段规则写注释，记录用途和添加日期。例如：
# 家庭局域网设备不经过代理
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
# 工作平台使用独立策略组，名称需与当前配置一致
- DOMAIN-SUFFIX,example.internal,工作节点如果客户端覆写界面不支持注释或不支持直接编辑 YAML，可以在本地单独保存一份文本备份。重点不是格式多漂亮，而是未来能知道每一条规则为何存在。
第三层：独立的本地配置或规则集
当自定义规则变多，例如需要维护几十个域名、多个设备网段、不同场景的代理策略时，应考虑把规则拆到独立文件或规则集里。这样更新订阅时无需反复复制，也不会让一份覆写文件变得难以阅读。
使用独立规则集时，建议坚持两个原则：
- 来源要明确，优先使用自己可审阅、可长期维护的规则内容；
- 规则集失效时要有降级方案，例如确保局域网直连等关键规则仍在本地覆写中。
不要从来路不明的网页复制一大段“万能规则”。规则不仅会影响访问速度，也可能把本该直连的服务交给代理，或把需要代理的请求错误直连。
更新订阅前后的检查清单
每次对覆写做了修改，不必立刻大范围折腾。可以按下面步骤验证：
- 先备份：导出当前配置，或复制覆写文本到本地文件。
- 只改一个目标：例如先添加一个域名直连规则，不要同时动 DNS、TUN、规则集和代理组。
- 重新加载配置：确认客户端没有 YAML 或解析错误提示。
- 查看日志验证命中：访问目标站点，确认命中的规则与策略组正确。
- 手动更新一次订阅：更新后再次检查自定义规则是否仍然存在、是否仍能命中。
- 保留回退方案：如果更新后网络异常，先停用覆写或恢复备份，再逐段定位问题。
尤其要避免在网络已经无法使用时一次性改动多处设置。一次只改变一个变量，才能知道真正的原因在哪里。
不同客户端中该怎么找“覆写”入口
不同版本的 Clash Verge、Clash Party、FlClash、Android 上的 Clash Meta 客户端，以及其他使用 Meta 内核的工具，界面差异很大。通常可以从以下位置寻找：
- 配置详情页中的“覆写”“编辑覆写”或“脚本”；
- 订阅/Profile 页面中的“解析器”“订阅处理”；
- 设置中的“扩展配置”“Mixin”“Merge”；
- 高级设置中的“规则覆写”或“自定义规则”。
如果只看到“编辑配置”，先不要直接改订阅正文。确认该文件是否会随着订阅更新被重新下载；如果会，就把它视作临时测试用途，而不是长期方案。
另外，有些客户端的覆写只会对某一份订阅生效，有些则是全局生效。家里和公司使用多份订阅时，这个区别很重要：全局覆写里的规则可能意外影响所有配置。创建规则前，先确认覆盖范围。
总结：把订阅当底座，把个人规则当补丁
订阅更新后自定义内容消失，本质上是把“远端自动生成的配置”当成了“个人配置文件”使用。更可靠的做法是让两者各司其职：订阅持续更新节点与基础规则，本地覆写保存个人分流、局域网直连和 DNS 等偏好。
刚开始使用覆写时，建议只从一条最简单的规则开始，并通过日志确认它确实命中。等理解了规则优先级、代理组名称和 DNS 的关系，再逐步引入独立规则集或更复杂的策略。这样即使订阅服务端调整内容，也能在较少改动的情况下继续保留自己的网络使用习惯。