分流策略：三层规则表、30 分钟 出口粘性与内网白名单

§01

三层结构：命中顺序决定结果

规则表按「进程 → 域名 → 端口 → 全局」的顺序匹配，任一层给出明确结论即停止向下查找。顺序不是任意排的：越靠前的层携带的信息越确定，进程名来自操作系统，域名来自握手，端口只说明协议类型。

第 1 层

进程名，精确匹配可执行文件名

第 2 层

域名后缀，支持通配前缀

第 3 层

端口与协议，含端口区间

兜底层

全局开关，命中不到时生效

为什么进程层排在最前

进程名是唯一不依赖网络报文的信号：它在本机就能确定，不需要等待握手，也不受加密流量影响。把最确定的信号放在最先匹配，能让多数会话在第一跳就定下结论，减少握手阶段的等待。

为什么端口层排在最后

端口只说明协议类型，不说明业务性质。同一个 443 端口可能是流媒体、可能是企业后台，也可能是游戏登录。把它放在最后，是为了让前两层有机会给出更精确的结论。

§02

进程层：按应用而不是按域名分流

跨境办公最常见的痛点不是速度，而是「内网后台被代理」。按进程分流能从根上解决：浏览器走加速，办公套件与内网管理工具保持直连，两者在同一台机器上互不干扰。

默认规则为什么带「可改」一列

默认值只是起点，不同岗位的取舍完全不同：外贸运营希望邮件客户端走加速，内网运维则希望所有数据库工具直连。把可改性写在表里，是为了让用户知道这不是黑箱，而是一份可以覆盖的初始配置。

进程识别的两个边界

一是同名不同版本的进程会被同一规则命中，例如两个不同安装路径的 chrome.exe；二是子进程默认继承父进程规则，只有在子进程自身出现在表里时才单独判断。这两条边界写在客户端的规则说明里。

§03

域名层：整组继承同一出口

域名层的价值是保持一致性：一个页面里的图片、接口与统计脚本如果分属不同出口，登录态与风控判定就会互相矛盾。域名层的做法是按后缀归组，让整组继承同一出口。

通配前缀的匹配代价

通配匹配需要把域名按标签切分后逐级比对，成本高于精确匹配。规则库因此把高频域名单独列为精确项，只对长尾使用通配，实测匹配耗时从 0.4 毫秒降到 0.1 毫秒以内。

加密流量如何拿到域名

TLS 1.3 的加密 SNI 会让域名不可见，此时域名层失效并落到端口层。客户端对这种流量的处理是「按进程兜底」，也就是把域名判断让给上一层，而不是猜测域名。

规则库的规模与维护

当前 1.8 万条，其中 412 条为开发类站点分组，10 月新增。规则库由三人维护，每周复核一次误报清单，误报的定义是「用户手动锁定后连续 3 天不再改动」。

§04

端口层：兜底但仍可覆盖

端口层不是「猜业务」，而是给协议一个默认归宿。UDP 443 走 QUIC 通道，游戏端口进优先队列，其余按全局开关处理。所有默认都可被前两层或手动锁定覆盖。

为什么 UDP 单独列

UDP 没有重传机制，丢包直接表现为卡顿或瞬断。把 UDP 443 单独归入 QUIC 通道，是为了让无连接流量在拥塞时优先获得转发，而不是与大批量下载抢同一条队列。

端口区间如何避免误伤

27015 至 27050 是主流对战服的常用区间，但同一区间也可能被其他程序占用。客户端会在建立连接时检查进程名，若进程不在游戏白名单内则退回普通队列，避免把无关流量塞进优先通道。

§05

会话保持：出口粘性怎么算

频繁跳出口会让登录态失效、风控触发、长连接断开。出口粘性的做法是「同一目标站点在窗口期内不换出口」，窗口期取 30 分钟，与多数站点的会话超时对齐。

1. 首次访问某站点时记录目标域名与选定出口，写入本地粘性表。
2. 窗口期内该域名的所有连接复用同一出口，即使有另一条线路评分更高。
3. 窗口期结束或连接全部断开超过 5 分钟，粘性记录失效并重新选路。
4. 用户手动切换节点时清空整张粘性表，避免旧出口残留导致行为不一致。
5. 粘性表最多保留 200 条，超出后按最久未使用淘汰。

粘性带来的代价

窗口期内若原出口劣化，用户可能在 30 分钟内无法自动切到更优线路。这是刻意的取舍：对多数站点来说，稳定的出口比最快的出口更重要。异常劣化（丢包超过 5%）会强制打破粘性。

粘性与多标签页的冲突

同一浏览器打开多个标签访问同一站点时，粘性表按域名而非标签记录，因此所有标签共享同一出口。若用户希望对不同标签使用不同出口，只能手动锁定，这是已知限制。

§06

内网直连白名单：默认不动的十个网段

内网直连白名单不可被全局开关覆盖。它覆盖 RFC1918 定义的私有网段、链路本地地址与本机回环，命中即直连，任何规则都不得改写这条默认。

为什么这条默认不能关

内网服务没有公网可达性，一旦被代理就会直接超时。把白名单设为不可覆盖，牺牲了一点灵活性，换来的是「装完客户端打印机还能用」这个最基本的预期。

内网域名后缀同样生效

除 IP 段外，常见内网后缀（.local、.internal、.corp、.lan）同样命中直连。后缀表可扩展，但不可删除内置项，扩展项随订阅同步。

§07

规则更新与回滚

规则库每 12 小时下发一次，紧急变更走独立通道。更新失败时保留上一版，连续两次失败在界面提示并停止重试，避免把用户困在更新循环里。

1. 配置中心发布新版本，附带版本号、变更条数与校验值。
2. 客户端拉取后先校验，再在内存中试解析，解析失败直接丢弃并记录一次失败。
3. 试解析通过后原子替换本地规则文件，旧版本保留为上一份。
4. 替换后 10 分钟内观察误报率，若用户手动锁定次数超过阈值则自动回滚。
5. 回滚事件写入本地日志与公告页，保留 30 天供核查。

§08

可观测性：每条会话都能解释

分流系统的最大问题是不可解释：用户不知道为什么某个站点走了直连。客户端的「连接详情」列出每条会话命中的规则编号、匹配层级与出口，这是可解释性的最低要求。

为什么把规则编号暴露给用户

规则编号是可核查的最小单位：用户可以在规则说明里查到 R-010 的具体内容，也可以把编号写进工单。只给「已加速」三个字，等于什么都没解释。

一张规则表的维护成本

1.8 万条规则由三人维护，每周约处理 40 条误报、新增 25 条站点分组。人力成本换算下来，每条规则的平均维护时间不足 3 分钟，这也是规则库必须自动化的原因。

白名单与分流规则的关系

白名单是「先于所有规则」的硬约束，分流规则是「在有公网可达性的前提下」的软选择。两者不在同一层，因此修改分流规则不会影响内网可达性，这也是把白名单做成不可覆盖的原因。

白名单与订阅的边界

白名单不随订阅变化，它是客户端内置的硬约束；订阅只影响节点清单与规则库。这样设计的理由是：内网可达性属于基础功能，不该被账号状态影响，也不该被一次误配置写坏。

一处已知的长期取舍

域名层的通配规则无法覆盖「同一 CDN 域名下既有境内站点又有境外站点」的情况，这类冲突只能靠精确项逐条覆盖。目前已知的冲突域名有 37 个，全部以精确项形式加入，逐月复核一次。

为什么不做「智能自动改写规则」

自动改写会把不可解释性放大：用户不知道规则何时被改，也无法复现上一次的结果。我们选择「规则固定 + 可手动覆盖」，把不确定性交给用户显式决定。

日志的留存边界

连接详情只在本地保留最近 500 条，不上传。需要排查问题时由用户手动导出，导出内容包含规则编号与出口，不包含 URL 与页面内容。

§09

误判处理与边界

任何规则库都会有误判。区别在于误判之后用户能否在一分钟内自愈，以及误判是否会被记录并进入下一版规则。

• 手动锁定：在连接详情里把某站点锁定到指定出口，锁定优先于所有自动规则。
• 临时直连：右键托盘图标可临时绕过分流 10 分钟，用于排查是否为规则问题。
• 误报反馈：一键提交规则编号与现象，不需要上传任何页面内容。
• 不承诺：不保证任何站点的访问结果，规则只决定出口，不改变目标站点的可用性。
• 不记录：不记录访问的完整 URL，连接详情只保留域名与规则编号。
• 可回滚：规则库保留上一个版本，出现大面积误判时可一键回到上一版。

把边界写在最后而不是藏在条款里，是因为分流策略的本质是一组取舍：稳定优先于速度，可解释优先于智能。读者认可这组取舍，规则表才有意义；不认可，也可以手动改成自己需要的样子。

• CN2 GIA 回程线路回程如何影响分流结果
• 延迟实测测速时要先排除分流干扰
• 客户端下载规则随客户端版本更新
• 常见问题分流相关问题的答复

三层规则出口粘性内网白名单规则回滚可解释性

§10

数据快照与来源：可单独引用的六条记录

本节把页面内散落的数字集中成六条记录，每条都带测量条件与来源，可脱离上下文单独引用。按主题查阅请回到上文对应章节。