SStap 用久了最常出现的现象是规则写了但没生效：新加的规则明明条件命中，流量却按另一条规则走了。原因在于规则是按次序判定的，先命中的规则直接终结判断，后面的规则根本没被执行。代理IP线路的分流规则写多了之后，冲突的概率随规则数量上升，代理IP线路的实际走向就由命中的第一条规则决定。本文按四步排查法讲 SStap 里这类冲突怎么定位，不靠反复改配置去试。
第一步是确认现象属于优先级冲突，而不是规则本身写错。区分方法很简单：把疑似冲突的两条规则临时禁用其中一条，再跑同一批业务。禁用之后现象消失，说明两条规则之间有覆盖关系，属于优先级冲突；禁用之后现象不变，说明生效的那条规则本身条件写错了，属于规则缺陷。两种问题的处理方式完全不同，混在一起改配置会把人绕晕，这一步值得花时间做扎实。
第二步是把规则的命中顺序列出来。SStap 的规则列表是可以看顺序的，把当前所有启用规则按次序抄一份，每条标注三个信息：匹配条件、目标线路、启用状态。这份抄本比软件界面好用，因为冲突通常出现在相隔很远的两条规则上，界面上滚来滚去看不到全貌。列的时候顺手做一件事——把条件里出现”任意”或”全部”的规则挑出来单独标记。范围过宽是优先级冲突的主要来源，绝大多数覆盖问题都出在这几条上。
第三步是找交集。对标记出来的宽规则，逐条问一句：它会不会把窄规则想接走的流量提前拿走。判断方法是看业务的目标地址或端口是否同时落在两条规则的范围内。落在两条里，就构成了冲突。这一步有个实用技巧：不要按规则顺序找，要按业务顺序找。从实际业务出发反推它被哪条规则接走，比从规则出发预测它会接走谁准确得多——批量环境里业务清单是确定的，而规则的意图会随时间模糊。
第四步是调整而不是删规则。冲突确认之后，处理顺序建议按三步来。第一步调顺序，把范围窄的移到范围宽的前面，这一步能解决大部分冲突且不改任何条件。第二步缩范围，如果顺序调整后仍有重叠，把宽规则的条件收紧，删掉已经被窄规则覆盖的部分。第三步才是加例外——为特定业务单独插一条最靠前的规则。加例外是最后手段，因为它会让规则数量继续增长，例外加多了，下一轮冲突排查又会变难。
调整完之后必须复验。复验的最小集是两类业务：一类是被窄规则接走的业务，确认它仍然走预期线路；一类是被宽规则接走的业务，确认它没有被误调出去。只看被修的那一条业务是不够的，优先级调整的影响面从来不止一处。代理IP线路在这一步上要一起核对，把实际出口与目标线路逐条对上，只看软件状态显示容易漏判。
长期避免这类冲突，靠的不是配置技巧，而是三条约束。一是规则数量设上限，批量环境里启用规则超过几十条之后就应当合并同类项，而不是继续新增。二是每条新规则必须写明意图，写不出意图的规则不要加。三是宽规则集中管理，把”任意匹配”类规则固定放在列表末尾，中间位置只允许窄规则，这条约束执行半年，冲突排查频率会降下来很多。
还要补一条 SStap 特有的经验：规则文件改动之后不要只看软件界面显示已保存，要确认改动已经作用到正在运行的服务上。个别情况下配置写进了文件但服务没有重载，现象是新规则完全不起作用，容易被误判成优先级冲突。排查冲突之前先排除”根本没生效”这一种，能省下大量无用功。代理IP线路在这类场景下的表现尤其迷惑——旧规则仍在生效时，出口看起来完全正常，只是不符合新的分配意图。
SStap 的分流逻辑本身不复杂，冲突问题的根源在于规则列表是一个随时序演化的东西：每条规则单独看都合理，叠在一起就可能互相遮蔽。把抄本、复验和三条约束变成习惯，规则列表才能长期保持可维护，而不必攒到某个季度集中清理一次。
问：两条规则条件完全不重叠，还会冲突吗？
条件不重叠则不会互相遮蔽，但要注意隐含重叠：一条按端口匹配、一条按目标地址匹配，两者条件维度不同却可能命中同一请求。判断交集要按实际流量验证，不能只看条件文字。
问：临时禁用规则会不会影响在跑的业务？
会，已建立的连接可能继续保持原路径，新连接才按调整后的规则判定。所以禁用测试要放在低峰时段，且测完立刻还原。