客户端分流规则的作用，是把进入客户端的连接交给合适的出口。要写出可维护的规则，先列出哪些应用需要直连、哪些业务需要代理、哪些连接应当拒绝，再用连接日志验证命中结果。把一份大型规则集合直接导入，并不能证明它符合自己的网络环境。
先把使用需求写成可以检查的句子
例如，一台家庭电脑需要访问局域网打印机，浏览工作资料，同时通过指定出口访问某个在线服务。需求应写成“打印机地址走本地网络”“工作站点使用公司要求的连接方式”“在线服务的新连接进入指定策略组”。这比“国内直连、国外代理”更具体，也能避免把企业内部域名按地域误分类。
为每个需求准备一项测试动作：打印一页测试纸、打开内部登录页面、请求在线服务的轻量页面。记录预期出口和成功标准。某个网站首页能显示，只代表部分资源可达；登录、上传和接口请求可能使用不同域名，应分别观察。不要一开始就添加数十个猜测出来的域名。
理解匹配条件和策略选择的分工
域名规则回答目标是谁，地址规则回答目标落在哪个地址范围，进程规则回答连接由哪个程序发起。策略组则回答匹配以后交给谁处理。同一条规则命中后，策略组内部选中的节点仍可能改变，因此“命中了代理组”与“使用了预期出口”需要分别确认。
以核验时的 mihomo 文档为例，规则按从上到下的顺序判断，完整域名、域名后缀和关键字匹配具有不同范围。具体行为以所用内核版本为准。一般维护时，把窄范围例外放在宽范围集合之前，兜底行为放在最后，但不要将这一经验机械套用到具有不同动作语义的内核。
完整域名适合一个明确的接口；后缀规则会涉及其子域名；关键字容易扩大影响范围。示例中，若只想调整办公系统的登录接口，就先对该接口作精确例外，确认业务链路以后再考虑扩大范围。用一个公司名关键字匹配全部连接，可能误伤名称相似的无关服务。
一次只增加一条可解释的变化
先保存当前有效配置和客户端、内核版本，在本地覆盖层增加规则，不要直接修改下一次订阅更新就会覆盖的远程内容。规则引用的策略组必须真实存在，名称中的空格和大小写也应保持一致。修改后先进行配置校验，再重新载入，出现解析错误时立即恢复上一份配置。
重新发起测试前，应关闭对应页面或结束相关连接，让应用建立新连接。已经建立的连接可能继续沿用原有出口，仅刷新页面不一定足以触发新规则。观察时间、进程、目标域名、命中规则、策略组和最终节点，把这些信息放在同一条记录中，才有完整证据。
假设某个接口仍然直连，先问连接是否进入客户端。如果连接列表没有它，问题可能在系统代理作用范围，而不是规则优先级。如果连接存在但只显示地址，需要检查解析、嗅探或入站提供的目标信息；不要立即把整个地址段加入代理，因为共享基础设施可能承载很多无关业务。
处理兜底与例外的冲突
兜底必须体现自己的使用意图。偏向代理的兜底能减少未分类连接直出的机会，但可能影响本地业务；偏向直连的兜底更依赖准确的代理集合。没有一种兜底适用于所有家庭、公司和移动网络。确定后应记录理由，避免后续维护者看到连接异常就反复切换全局模式。
遇到局域网资源失败，先核实地址范围、访问方式和本地防火墙。不要把所有私有地址都当作同一台设备，也不要为修复一台打印机而关闭全部过滤。若企业网络使用自己的隧道，确认两套接管机制能否共存；涉及工作环境的设置应遵循组织要求。
规则集合更新以后，原先的局部例外可能不再必要。为例外加上原因、日期和复查条件，例如“此接口暂时未被上游收录，待下一版规则核实”。过期例外积累越多，排错越容易绕入历史问题。维护的目标是更少、更明确的规则，而不是让文件长度不断增长。
用一张小清单结束修改
最后复测本地资源、目标业务、普通网页和一个不应匹配的相似域名。检查新连接的出口，同时观察是否产生额外解析失败。把“通过”限定在实际测试的设备和网络，不要根据单台电脑的结果宣布全家所有设备都已正确分流。
继续维护时，可参考规则集合更新审查管理上游变化，通过双栈出口核验确认另一地址族没有遗漏，并用订阅与本地覆盖层保留个人需求。分流配置真正可靠的标志，是每条例外都说得清、每次修改都能回退。
多人共用同一配置时，还应把个人例外与家庭共用规则分开管理。新增一条工作域名规则之前，确认其他设备是否使用相同服务却需要不同出口。如果需求确实冲突，应使用独立配置或受支持的设备区分方式，不要靠轮流改变同一个策略组维持工作。
参考资料
- mihomo 路由规则，核验日期：2026-10-15。
- sing-box 路由配置，核验日期：2026-10-15。