启航加速器智能分流拆解：18 万条规则，12 毫秒内给出出口

一个请求该直连还是走隧道，答案要在浏览器发出连接之前给出。启航加速器 3.2 版的客户端把这个判断压到平均 12 毫秒，规则库规模 18 万条。10 月 16 日，研发组第一次完整公开了这套判定链路。

全局代理的时代基本过去了。把整机流量一股脑塞进隧道，境内站点会绕一圈回来，视频网站还会因为出口在境外触发版权限制。用户真正的诉求是“该走隧道的走隧道”，这需要一套足够快、足够准的分流规则。

六层判定，命中即短路

启航加速器的判定顺序是固定的：自定义规则、应用特征、地区库、域名后缀库、IP 归属库、默认直连。任何一层命中就立即短路，不再向下走。这个顺序不是随口定的——把用户自己写的规则放在最前面，是为了让“我知道我要什么”的场景永远优先于系统的猜测。

应用特征层是 3.1 版之后新增的。它不看域名，看进程：某些客户端会把请求发到大量随机子域，域名库追不上，但只要识别出进程名，就能整体归类。目前内置特征 2400 余条，覆盖主流开发工具、网盘、会议软件与游戏启动器。

六成三的请求，其实不需要隧道

我们从 9 月的抽样里取了 120 万次请求做统计：63% 判定为直连，29% 走智能加速，5% 命中用户自定义代理，3% 落入阻断清单。这个分布说明一件事——大部分流量本来就该走本地网络，硬拉进隧道只会让页面变慢。

29% 的智能加速份额里，视频与社交占了大头。有意思的是工作日与周末的结构差异：工作日开发工具与文档站点的加速请求占比高出 11 个百分点，周末则被影音拉高。这个差异直接影响了我们后来在晚高峰的带宽预分配策略。

规则库怎么更新，才不会把用户的配置冲掉

规则库每周随客户端更新一次，增量下发，单次体积控制在 400KB 以内。用户自定义规则单独存一个文件，版本升级时只做合并、不做覆盖；遇到同一域名在两处出现，以用户规则为准。这个设计来自一次事故：2025 年 11 月的一次全量更新把部分用户手写的正则清空了，虽然当天修复，但那之后我们加了双份备份。

12 毫秒是怎么省出来的

规则匹配本身不难，难的是不能每次都全表扫描。客户端启动时把规则编译成前缀树与哈希表的混合结构，域名按倒序后缀建树，IP 段用二分查找，进程名走哈希。命中后的结果写入 60 秒 TTL 的本地缓存，重复请求直接取缓存。三层叠加之后，单次判定从 3.0 版的 31 毫秒降到 12 毫秒。

“12 毫秒听起来不大，但一次页面加载可能有 80 个请求。”客户端负责人李工说，“原来光分流判断就吃掉两秒多，现在这 12 毫秒是平均值，P95 也只有 26 毫秒。”这个数字在弱一点的机器上会翻倍，所以我们额外做了低性能模式，把前缀树换成线性小表。

想自己验证效果，可以在核心功能页看到完整的规则说明，或者直接从下载页装一份客户端，在设置里打开“显示分流决策”，每个请求走了哪一层、耗时多少都会打在日志里。

← 返回新闻列表