规则与策略组分别负责什么
规则描述连接满足什么条件时交给哪个目标，策略组则组织可供选择的出口。直接访问、经过代理以及拒绝连接是不同处理结果。应先明确目标请求，再从规则追踪到策略组，避免把所有异常都理解成节点速度问题。
例如某个网站访问方向不符合预期时，先确认请求的真实域名和命中规则，再看规则引用的策略组当前选择。网页经常包含多个域名，首页能打开并不代表图片、登录和接口请求都使用相同路径。
顺序会影响最终结果
规则按从上到下的顺序检查。较宽的条件如果放在前面，可能先匹配而让后面的具体规则失去作用。整理规则时先写清楚例外，再考虑一般条件，并检查最终没有命中其它规则的连接应如何处理。
不要凭名称猜测优先级。修改前保存原配置，每次只调整一处条件或位置。使用相同目标请求复测，并记录命中的规则与出口，这样才能说明变化究竟来自排序、目标内容还是策略选择。
从简单域名匹配开始
完整域名与域名后缀匹配的范围不同。下方示例使用保留示例域名说明语法和直接访问处理，不含可用代理资源。真实配置中还可能有其它规则；加入片段前应核对名称、顺序和当前版本文档。
按 IP 的判断可能涉及解析结果，按域名的判断则需要看客户端能获得的目标信息。不要因为浏览器地址栏中的名称相同就假定底层请求完全一样。先从清晰的域名规则开始，再逐步引入复杂条件。
rules:
- DOMAIN,example.com,DIRECT
- DOMAIN-SUFFIX,example.org,DIRECT
- MATCH,DIRECT处理冲突需要最小复现
出现冲突时先临时缩小问题范围：保留与该目标相关的规则，记录原顺序，并对照实际命中结果。若使用远程规则集，要确认它已加载，类型与引用名称相符，内容更新时间符合预期。
策略组名称相似、组内成员无效、兜底条件过早，以及规则集取回失败，都可能造成看似相同的现象。逐项排查比整份配置替换更容易找出原因。恢复原配置后再逐步加入确认有效的改动。
验证不应只有一次测速
测试规则时，重点是请求是否走了预期路径，而非只看某个延迟数字。分别检查页面、静态资源和接口，必要时重新发起请求，避免缓存掩盖真实行为。连接日志可能包含访问目标，共享前要脱敏。
如果策略正确但访问依旧失败，继续检查基础网络、DNS、远端资源和目标服务本身。规则只能决定处理方式，不能保证被选择的连接资源始终可用。将匹配结果和实际可用性分开记录，能让排错更有条理。