一句话结论：分流问题九成在规则表，剩下的一成在环境与链路。只要先看状态标记，就能把范围从「整张规则表」缩小到「某一层」。

排查总流程：五步定位

下面这五步是演练环境里固定使用的顺序。每一步都有明确的判断依据，走完一步就能排除一类原因。

1. 1
   看状态标记：打开状态页，看最近一次请求显示的判定层与方向

   • 标记显示未命中，问题在规则表
   • 标记显示命中但访问异常，问题在链路
2. 2
   确认判定层：根据标记判断是域名层、网段层、应用层还是名单层命中

   • 域名命中说明域名层有条目生效
   • 名单命中说明使用者自己指定过
3. 3
   核对规则表：导出规则表，检查目标对应的条目位置与写法

   • 先查同层是否有更靠前的条目
   • 再查字段是否写对
4. 4
   确认环境：确认授权、权限与路由改写三项条件是否满足

   • 受管终端上规则保存也不会生效
   • 同时运行其它工具会覆盖路由
5. 5
   确认链路：把流量锁定到一个方向做对照测试，排除链路侧原因

   • 对照测试约 2 分钟
   • 两种方向表现相同即为链路问题

为什么先看状态标记

状态标记把排查范围直接分成两半。显示未命中，说明规则表里没有覆盖这个目标；显示命中，说明规则没问题，后面三步查的都不是规则。

为什么最后才看链路

链路问题与规则问题的现象几乎一样，都是打不开或变慢。先排除规则，可以避免在链路正常时反复改规则。演练环境里，顺序照做能省掉约七成的无效改动。

第一步：状态标记的四种读法

状态标记是整个排查的起点，下面把四种标记分别对应到可能的原因范围。

标记会跳动的正常现象

连续访问不同站点时，标记在几种之间来回跳动，这是正常现象。标记只反映最近一次请求，不反映整体覆盖率。

看不到标记时怎么办

判定日志必须处于开启状态才能看到标记。演练环境里约 14% 的「看不到标记」反馈，实际是日志开关被关掉了。

标记读法的四条提醒

标记本身信息量很小，要结合上下文才有用，下面四条是读标记时最容易出错的地方。

第二步：确认判定层

确认了方向之后，下一步是确认生效的是哪一层。层决定了你该改哪里，这一层的错误占全部失败的 38%。

层被覆盖的两种情形

一种是跨层覆盖：你写的条目在低层，而高层已有条目命中。另一种是同层覆盖：同层内靠前的条目先被采用，你写的那条成了冗余。

最容易漏掉的一类

手动锁定一旦打开，全部规则都不参与判定。这类情况在演练统计里只有 2 例，但因为外观上与「规则完全不生效」一模一样，排查时经常被跳过。

第三步：核对规则表

确认问题在规则表之后，就进入具体条目的核对。下面给出四个核对方向，每个方向都有固定的检查动作。

核对一：条目是否存在

在规则表里搜索目标的主域名，如果搜不到，说明规则表根本没收录这个目标，属于缺漏，补写即可。

核对二：条目位置是否正确

条目存在时，看它在本层的位置。同层内靠前的条目优先，例外条目应放在首部，位置不对时现象是方向与预期相反。

核对三：写法是否正确

按八种指令与三段字段核对，方向写反属于语义错误，导入时不会提示，只能靠实际访问发现。

核对四：同层是否有方向冲突

把同一层的条目按方向分组排序，两个方向都存在的部分就是潜在冲突点。演练环境里 4 例同层冲突都这样找出来。

导出规则表时的三个检查点

排查时导出的规则表不只是用来读，还是用来对照的。下面三个检查点能在导出后立刻发现大部分问题。

第四步：确认环境

如果状态标记显示未命中，而规则表里明明有对应条目，就要看环境。下面四项是演练环境里最常见的落地障碍。

受管终端是最容易被误判的一类

公司终端上规则能保存、界面显示正常，但判定永远不生效。此时改规则完全无效。演练环境里把这一类的识别放在第四步，就是为了避免在规则上浪费时间。

同时运行多个工具的表现

两个工具同时接管路由时，后写入的会覆盖先写入的，表现为规则时灵时不灵。这类现象最容易被误判成规则问题，实际上退出其中一个工具即可解决。

第五步：确认链路

前四步都排除了，问题就在链路侧。判定正确但访问仍然异常，这是链路问题的典型表现。

对照测试怎么做

把流量手动锁定到一个方向，观察目标是否可达；再锁到另一个方向重复一次。两次表现相同，说明与判定无关，问题在链路或目标服务本身。

对照测试的三种结果

两次都通，说明是规则问题，回到第三步。两次都不通，说明是链路或目标服务的问题。只有一次通，说明规则本身是对的但选错了方向。

链路问题的三个可观测特征

抖动明显偏高、重传次数多、首屏时间随时间波动。这三个特征与判定无关，可以作为链路侧的旁证。

对照测试前的准备

对照测试要改变全局方向，准备工作有三项，跳过准备会让测试结果失去可比性。

现象一：规则写了却不生效

这是最常见的一类，演练环境里的 100 例失败中有 38 例属于此类，下面按具体成因拆开。

成因一：被更高层覆盖

占比最高，条目写在了低层，而高层已有条目命中。处理方式是把条目提到对应的高层，或者收窄高层的覆盖范围。

成因二：同层位置不对

条目存在，但同层里靠前的条目方向相反。把例外条目挪到本层首部即可，改动量通常只有一两行。

成因三：手动锁定未解除

锁定状态下全部规则都不参与判定。这类现象的特征是状态标记只显示一个方向，不显示层名。

现象二：目标站点仍然打不开

这一类要区分判定侧与链路侧，判断依据是状态标记。标记未命中说明规则缺漏，标记命中说明问题在别处。

规则缺漏的两种情形

一是规则表没有收录这个目标，二是收录了但只写了主域名，漏了实际访问的接口或分片地址。后者更隐蔽，因为主站是能打开的。

链路侧的三个表现

所有目标都打不开、同一时间其它人也打不开、换节点后仍然打不开。这三条同时成立时，不必再查规则。

现象三：速度没有变化

这一类的核心是「变化是否可测」，很多用户说没变化，实际是差异小于测量精度。

先确认差异是否可测

把同一站点在两种设置下各测 10 次首屏取中位。两次差异小于 0.3 秒时，人耳无法分辨，这不是分流失效。

再看是不是本来就该走直连

本地站点在全部代理下也会变慢约 1.5 秒。这个变化存在，但多数人不敏感。若目标是本地服务，变慢是预期结果而不是故障。

现象四：改了规则之后别的站点坏了

这一类几乎都由覆盖范围过宽造成，演练环境里的 9 例中有 8 例是关键字过于通用，1 例是网段段宽过大。

关键字过宽的识别

在日志里找出命中数异常高的那一条，演练环境里判定标准很简单：一条关键字命中超过 20 个目标，就应当收窄。

网段过宽的识别

段宽超过 256 个地址且同段内出现本地服务，就要拆细。这类误伤通常表现为本地站点整体变慢。

现象五：登录后被登出

这一类只发生在需要固定出口地址的业务系统上。它不是故障，是出口地址变化触发了对方的校验。

三个识别特征

第一，登录成功后短时间内被断开。第二，其它目标访问正常。第三，状态标记显示代理命中但请求走的是跳转地址。

处理办法

把登录后的跳转地址写进名单层的直连集合，并在该地址上禁用解析选项。演练环境里这样处理后，办公类系统的重复登录从每日 6 次降到 0 次。

为什么跳转地址是根因

这类系统的登录流程往往分成两段：主站提交凭据，随后跳到另一个地址完成会话建立。第一段走代理没有影响，第二段如果落到默认出口，出口地址变化就会触发对方的校验，于是会话刚建立就被断开。

把跳转地址单独写进名单层，等于告诉判定引擎这两个地址必须走同一条通道。演练环境里的 6 例同类问题有 5 例是跳转地址没有规则覆盖，补写之后全部消失。

现象六：手机端与电脑端表现不一致

两端规则表相同，表现却不同。九成原因是两端的可用维度不一样，剩下的原因是规则表本身没同步。

最常见的三个差异

进程名与包名的写法不同、移动端不支持部分网段写法、iOS 没有独立名单层。三条都会让同一条规则在两端落在不同的层。

规则表不跨设备同步

快喵VPN 的规则表保存在本地，不随账号同步。两端要各自配置，跨端迁移需要按维度转换，方法见 下载客户端 页。

排查用的日志读法

判定日志在排查中承担两个作用：确认单次判定，以及统计未命中目标。下面说明这两类记录的字段。

单次判定记录

每次请求记录目标标识、生效层、方向与耗时四件事。看这一条可以确认某次请求到底被哪条规则处理。

未命中清单

统计窗口内没有命中任何条目的目标会进这份清单。它是补写规则的依据，也是发现关键字过宽的第一现场。

日志不记录什么

日志不记录请求内容与响应体，也不记录访问的具体页面。它记录的是判定行为，这是分流排障真正需要的信息。

排查自查清单

下面这份清单按排查顺序排列，共十二项，逐项走完，多数分流问题能定位到具体一处。

清单的使用方式

前九项查规则侧，后三项查环境与链路。如果第 4 项就显示命中，可以直接从第 12 项开始，节省掉大部分时间。

排查的时间预算

排查最怕的是没有节奏，在每一层都反复试，下面是演练环境里 100 例失败的实际耗时分布，可以作为参考。

把时间花在判断上，而不是试错上

上表里 75% 的案例在 6 分钟内定位，它们的共同点是按顺序走，没有跳步。先确认状态再动规则，比反复改规则测试要快得多。

什么情况该停下来换思路

如果同一层连续核对超过 3 次都没有发现原因，就该换一个排查维度，而不是继续在同一层找。下面三条是明确的停止信号。

复现与留证

分流问题有时只在特定时段出现，无法当场复现。留下可复现的证据，比凭印象描述有效得多。

留证的六项内容

下面这六项是演练环境里记录的最小集合，缺任何一项，对方都可能无法判断问题所在。

为什么对照目标很重要

只记录出问题的目标，无法判断这是个别现象还是整体问题。补上一个能正常工作的对照目标，对方就能立刻确认问题范围。演练环境里，附了对照目标的反馈，平均少一轮追问。

复现的两个条件

要复现一个分流问题，需要同一份规则表与同一个目标。目标能复现但规则表不同，判断结论会完全不同，所以规则表条数与所在层必须一并记录。

常见排查问题

下一步

排查方法讲完了。下面三页分别对应判定顺序、三类场景与规则写法，遇到具体问题时按需查阅。