规则分流为何存在
对使用代理IP做精细控制的人来说，规则分流形态出现的背景很实际：不是所有流量都需要走代理——本地服务的流量、某些必须直连的应用，走了代理反而添乱。规则分流把「哪些走代理」的决定权交还给使用者，用规则表达需求，验证也因此多了一层「规则对不对」的检查。
除了协议类型，代理IP的接管形态也影响验证方式：全局模式让所有流量都走代理IP，规则分流只让匹配规则的流量走。形态不同，验证的重点与坑就不同——按形态调整检查方式，是首次配置验证里容易被忽略的一环。
全局模式的验证
全局模式的验证相对简单：所有流量都经由代理IP，验证时只要确认出口换了、业务通了，基本就到位了——因为不存在「部分流量没走代理」的疑问。全局模式的主要坑是某些程序或系统服务不走全局代理，验证时顺手确认一下即可。
规则分流的验证要复杂一层：只有匹配规则的流量才走代理IP，验证时必须确认「目标流量是否被规则覆盖」——规则没写对或没覆盖目标，流量会静默直连，出口验证就会失败。规则分流的验证重点，是确认规则与目标的匹配关系。
两种形态的验证差异
两种形态的验证差异集中在「验证对象」上：全局模式验证「所有流量都走代理IP了吗」，规则分流验证「目标流量被规则覆盖了吗」——前者是全覆盖确认，后者是定向覆盖确认。验证动作看似相同（看出口、看业务），但失败时的排查方向完全不同。
规则分流还有一个全局模式没有的检查项：规则本身的正确性——规则的匹配范围写宽了会把不该走的流量也带走，写窄了目标流量又漏网。验证时除了看目标通不通，还要顺带确认规则范围是否符合预期，避免规则与业务错位，这种错位在配置首次落地时尤其常见，值得多花几秒确认。
组合形态的验证
模式与类型组合起来，配置形态就更丰富了：全局加 HTTP、规则分流加 SOCKS5，各种组合的验证重点各不相同。组合形态下先分清「类型决定连接方式、模式决定接管范围」，再分别按各自的重点检查，就不会乱。形态切换也值得单独验证一次：从全局切到规则分流、或反过来，旧的验证结论不能直接沿用，重新跑一遍出口与业务验证，确认新形态下目标流量仍然走代理IP，再放心使用。
形态差异落到验证动作上还有一个直接结果：全局模式的验证可以少测「目标是否被覆盖」这一类问题，规则分流的验证则必须加测——形态选得越精细，验证清单往往越长。别嫌规则分流验证麻烦，它换来的是「只让该走的流量走代理IP」的精准控制，多花几分钟把规则验证到位，后续使用会省下大量「流量没走代理」的困惑。
形态差异讲完，首次配置快速验证的全部要素都齐了：三层框架、验证目标、结果解读、失败排查、类型差异、模式差异。最后一篇把它们收进一份清单，让这套方法能照着用、反复用。