先用精确域名规则验证需求，把广泛规则和兜底规则放在合适的位置，并观察实际匹配结果。
规则由条件与处理策略组成
可以把规则理解为一次明确的判断：请求满足什么条件，就交给什么策略。条件可能是完整域名、域名后缀或 IP 网段；策略可能是 DIRECT、REJECT 或配置中实际存在的代理组名称。规则里写了一个不存在的组名，无法凭空创建那组出口。
下面用保留示例域名说明格式，仅用于理解，不代表建议访问这些目标。正式配置前先确认自己要改变的具体请求，并查到当前配置中的真实策略名称。
rules:
- DOMAIN,portal.example.com,DIRECT
- DOMAIN-SUFFIX,example.org,工作代理组
- MATCH,默认代理组先选择能表达需求的最小范围
| 类型 | 匹配范围 | 适合的起点 |
|---|---|---|
| DOMAIN | 完整域名 | 只调整一个明确服务 |
| DOMAIN-SUFFIX | 指定域名及其子域 | 同一域下多个关联服务 |
| IP-CIDR | 指定 IP 地址段 | 已确认的网络范围 |
| MATCH | 剩余请求的兜底处理 | 列表末尾的默认去向 |
关键词和大范围网段虽然书写短，却可能影响不相关目标。首次改动优先缩小范围，成功后再判断是否确实需要扩大。地理分类数据也不是对每个网站用途的保证，不应替代实际连接检查。
规则顺序会决定谁先得到处理
官方规则文档说明规则按顺序检查，首先匹配的规则决定处理。针对单个域名的例外，应放在能覆盖它的宽泛规则之前。MATCH 属于兜底，放在需要生效的具体规则前面，会使后面的条件没有机会影响请求。
例如，同一域既有“整个域直连”，又有“其中一个子域交给某代理组”，应先安排更具体的子域要求。排错时不要只确认某条规则存在，还要查看它上方是否已有规则接走了同一请求。
通过独立入口保存个人调整
远程订阅更新可能重新提供原始内容。Clash Verge Rev 官方文档提供独立的规则编辑入口，适合保存个人调整；界面名称与具体范围随版本核对。修改前先备份，再给规则写一个自己能理解的用途说明。
- 记录目标域名、当前命中规则和当前出口。
- 确认需求是直连、阻断还是改用特定策略。
- 添加一条小范围规则，核对组名和插入位置。
- 保存并加载后检查实际连接，再决定是否保留。
用新连接验证，而不是只看网页结果
网页可能复用连接或显示缓存，因此保存规则后，应发起一个新的目标请求，并查看应用连接信息。核对目标、命中的规则及最终策略；一个页面还可能请求多个域名，主页面成功并不表示图片、登录和下载都使用相同路径。
如果规则没有命中，检查目标域名是否确实一致、是否处于规则模式，以及当前加载的配置是否包含修改。规则命中但连接失败时，再检查该策略组选中的节点。把“没匹配”与“匹配后失败”分开，判断才更明确。
订阅更新后复查依赖的名称
提供者可能调整代理组名称或节点列表。自定义规则仍存在，却指向已经改名的组，是容易遗漏的维护问题。更新后抽查重要规则，确认组名、模式和最终出口都符合预期。
如果只是添加少量规则，先使用可视化编辑；涉及扩展配置和脚本时，要阅读对应版本的合并方式，避免意外替换整个列表。相关内容见官方扩展说明。保留每次改动目的与恢复副本，便于以后删掉已经不需要的例外。
相关问题
规则存在却没生效，先查什么？
先查运行模式、当前启用配置和规则顺序，再用新连接确认目标是否真的符合条件。
DIRECT 就是关闭客户端吗？
不是。DIRECT 是该请求的直连策略，客户端及其流量接入方式仍可能保持运行。
可以直接把代理组名称写成 PROXY 吗？
只有配置中确实存在这个名称的策略才可以。组名应与当前配置完全对应，不要照抄示例。
资料与适用范围
本文以原创步骤解释操作思路，不声称已经在所有设备和版本上实测。菜单名称、默认值与兼容条件可能随版本变化，请结合当前项目说明核对。
需要修正内容？请阅读反馈与纠错，不要公开完整订阅或账户凭据。
