01规则、策略组和节点各做一件事

一套分流配置可以拆成三个问题：这条连接是什么，应该采用什么处理策略，最终由哪个出口执行。

规则负责识别条件，策略组负责组织选择，节点提供具体连接能力。把三个角色分开以后，配置中的大量名称会更容易理解，也能避免把某个策略组的名字误认为真实服务器。

例如，“视频服务”可以是一个策略组，里面允许选择多个地区节点；规则发现相应域名后，把连接交给这个组。改变组内选择，通常无需逐条改写域名规则。相反，如果目标没有匹配到预期规则，仅仅更换组中的节点也可能没有效果，因为该连接从一开始就没有进入这个组。

02规则匹配依赖能够观察到的信息

常见条件包括域名、域名后缀、目标地址范围、端口、网络类型和进程信息。

不同平台与内核能获得的信息不同：有的场景保留域名，有的场景只看到地址；进程识别也可能受权限和系统机制影响。因此“我写了进程规则”与“这次连接一定能按进程识别”并不是同一个结论。

域名和IP规则也不能随意互换。一个域名可能对应多个地址，多家服务也可能共享同一个地址。对共享内容分发网络使用很宽的地址规则，可能把无关服务一起纳入。具体域名规则通常更容易表达意图，但仍要考虑服务使用的其他域名与解析行为，不能只凭首页地址覆盖整个应用。

03顺序会决定哪条规则真正生效

在常见的自上而下匹配体系中，较早匹配的规则先决定处理结果，因此更具体的例外通常需要放在较宽泛规则之前。

最后的兜底规则负责处理没有命中的连接。具体软件可能还有子规则或其他机制，阅读配置时应以所用内核的实际语义为准，不能把所有客户端都当作相同规则引擎。

假设一个工作服务需要固定出口，但上方已有一条宽泛规则把它直接放行，后面的专门规则就可能没有机会生效。这不是节点故障，而是规则顺序与预期不一致。反复新增更多同义规则往往只会让配置更难维护。查看实际命中信息，才能判断问题出在识别条件、规则位置还是策略选择。

04自动选择与故障回退目标不同

手动选择组让使用者明确决定出口，自动选择组通常依据某种探测结果挑选候选项，回退组则关注当前选项不可用时如何转移。

负载均衡又是另一类策略，可能把不同连接分配给多个出口。它们都可以减少重复操作，但不存在一种对所有任务都最好的自动化方式。

延迟较低的探测结果，不保证目标应用登录或长连接表现最好。频繁切换出口还可能影响会话连续性。对于需要稳定地区或相对固定出口的任务，明确选择往往更容易解释；对于普通短连接浏览，适当自动选择可能更方便。策略应服务于任务，不应因为名字看起来高级就一律启用。

05远程规则让维护集中，也引入依赖

规则集把一批条件集中维护，客户端可以按约定获取更新，减少用户自己整理大量域名的负担。

与此同时，维护者对规则的修改会影响本地行为。新增一个域名、扩大地址范围或改变分类，都可能让连接走向不同出口。因此远程规则不是纯文字资料，而是能改变网络处理的配置输入。

评估规则集时，可以关注用途是否明确、更新记录是否可理解、获取失败时如何处理，以及能否保留已知可用版本。更新频率高不自动代表质量好，条目越多也不自动代表覆盖更准确。过宽、重复或失效规则可能增加误匹配与排查成本，适合自己用途的清晰集合通常更容易管理。

06维护目标是让每次选择都有理由

一套可维护的分流配置，应该能回答几个简单问题：哪些服务要固定出口，哪些本地资源应直连，未知连接交给谁，以及远程更新影响了什么。

名称应表达用途，而不是只用“组一”“万能”“极速”这类无法解释行为的词。层级也不宜过深，否则用户很难追踪最终选择。

修改后需要观察真实连接是否匹配预期，并保留回到稳定状态的办法。不要同时更换规则集、DNS方案和全部节点，再试图从一个错误页面判断是哪项变更生效。理解规则、策略与资源之间的关系后，才能把一次配置变更看成可解释的调整，而不是依赖复制粘贴碰运气。