Clash Verge Rev
先明确希望改变哪类流量
规则分流的目标是让指定请求使用预期出口，而不是让规则数量尽可能多。修改前先写下一个可验证目标，例如某个测试域名走指定代理组，或可信局域网资源保持直连。记录现有配置和代理组名称，保存备份。不要直接套用包含未知组名的大段配置，否则可能发生校验失败或意外路由。
区分规则、代理组和节点
规则决定请求交给哪个策略，代理组决定如何选择出口，节点是具体连接端点。只切换一个没有被当前规则引用的组，不会改变目标请求的路线。排查时应沿着请求、匹配规则、目标组、实际节点逐层检查，而不是只看界面上哪个节点被选中。DIRECT 表示直连，REJECT 表示阻断；不要把两者当作普通服务器名称。
理解匹配顺序
常见规则按顺序匹配，宽泛的条件放在前面可能遮住后面的精确条件，兜底规则应放在适当的末尾位置。可先使用你控制的测试域名验证一条简单规则，再逐步扩展。域名规则与 IP 规则的匹配条件不同；在检查结果时，要同时关注连接记录中的目标域名、IP 和规则类型，不能仅凭浏览器地址栏判断。
把修改放在可持续维护的位置
远程订阅刷新可能重写下载的配置。需要长期保留的自定义规则，应按照当前版本支持的覆写、扩展或脚本方式维护，并在应用前检查语法与组名。一次只加一条规则，应用后确认内核没有报错。避免在无法解释作用的脚本中粘贴密钥，也不要直接覆盖唯一一份可用配置。
验证规则真正生效
应用修改后，为测试目标建立新连接，再查看连接列表中的匹配规则和出口。已经存在的长连接可能继续使用先前的路线，必要时关闭测试应用后重新打开。分别测试应走代理、应直连和不受改动影响的目标，确认没有误伤。订阅更新后重复同样的测试，并保留简短的变更记录。
出现误分流时回退
如果修改后大面积连接失败，先恢复备份或移除刚添加的规则，而不是继续堆叠更多例外。检查目标组是否仍存在、规则是否被更早的条件匹配，以及当前是否确实处于规则模式。提交问题时给出脱敏的单条规则和测试现象，不要上传整份包含服务器凭据的订阅文件。