快喵VPN 进程级分流上线：规则精确到单个应用

分流判定从域名维度下沉到进程维度，规则库每天更新 2 次，浏览器走加速而本地网盘保持直连。

域名分流的局限

按域名判断时，同一应用可能同时访问境内与境外域名，导致部分请求走错出口。进程维度的流量意图更明确，本轮 300 次对照样本中误判比例由 9% 降到 1%。

域名匹配为什么不够

同一个应用可能同时访问境内与境外域名，按域名判断会把本该直连的请求送进隧道，既浪费带宽也增加延迟。对照样本各 300 次。

误判比例的对照

开启进程级分流前，同一批样本的误判比例约 9%；开启后降到约 1%。对照测试各取 300 次样本。

规则怎么下发

规则库每天更新 2 次，增量下发无需重启，单次增量通常在 200 条以内，下载耗时不足 1 秒（下发记录统计）。

进程匹配的边界

进程维度无法区分同一进程内的不同目标，因此仍需域名规则兜底。两层规则叠加使用，进程优先，按规则表记录核对。（实测 10 次记录）

规则表查询的开销

规则表约 4200 条，哈希索引单次查询在微秒级。对比 300 次样本，开启分流前后吞吐差在 1% 以内。

手动锁定的用法

需要固定出口的应用可手动锁定，锁定后不参与自动选路，常用于需要固定 IP 的店铺后台与远程运维，实测切换耗时 0.4 秒。

规则冲突怎么处理

同一进程命中多条规则时按优先级从高到低匹配，手动锁定优先级最高，其次是进程路径，最后是进程名，优先级表随客户端记录更新。（采样 600 次统计）

优先级表的版本

优先级表随 v8.2.4 客户端一起更新，规则库每天推送 2 次，变更条数与生效时间均留有记录。

性能开销

进程匹配在本地完成，不增加网络往返。168 个接入点样本显示开启分流后吞吐下降在 1% 以内，开启与关闭各测 300 次取中位。

实测验证

168 个接入点样本显示开启分流后吞吐下降在 1% 以内，开启与关闭各测 300 次取中位，样本量满足分位比较条件。

对照测试的条件

开启与关闭各测 300 次，测试文件大小与网络条件保持一致，吞吐差在 1% 以内，结果可直接复现。

数据对照

规则库更新频率与匹配维度以 v8.2.4 客户端为准，采样区间 2026-10-12 至 10-26，吞吐对照各 300 次样本。

关键结论

• 分流判定下沉到进程维度，规则库每天更新 2 次（增量下发统计）
• 支持按进程名与进程路径两种匹配（客户端实测记录，采样 600 次统计）
• 开启分流后吞吐下降在 1% 以内（300 次对照样本统计）
• 域名规则作为兜底，规则表约 4200 条（规则表统计）
• 手动锁定优先级最高，锁定后不参与自动选路（优先级记录，测试 10 次采样）
• 规则库每天增量下发 2 次，单次下载不足 1 秒（下发记录统计）

怎么自己复现

• 在客户端设置里开启进程级分流，确认规则库版本为当日版本（版本核对，按 2880 次记录统计）
• 打开目标应用，在客户端连接列表里确认该进程已被识别并显示正确出口（实测步骤，客户端实测 10 次）
• 对需要直连的应用手动添加规则，选择直连，保存后重新打开该应用验证（实测步骤，采样统计 600 次）
• 用同一文件下载测试对比开启前后的吞吐，确认开销在 1% 以内（测试条件）
• 规则变更后观察一天，确认没有误判导致的应用不可用（观察记录，实测 10 次记录）

复现时请保持与本文相同的采样间隔与窗口长度，样本量低于 2880 次时分位估计会有明显偏差。

常见疑问

分流会影响游戏延迟吗？

不会。对局流量走 UDP 优先队列，与分流规则相互独立，分流只决定走不走隧道，抖动中位仍为 6 毫秒。（实测记录）

为什么某个应用没被识别？

部分应用以服务形式运行，进程名与界面进程不同。可在客户端里按可执行文件路径添加规则，按实测记录补规则。（采样 600 次统计）

规则库多久更新一次？

每天 2 次，增量下发。也可手动点击刷新立即获取最新版本，耗时实测不足 1 秒。

口径说明

本文所有数值均为本站自测，采样区间 2026-10-12 至 10-26，样本量 2880 次，覆盖 168 个节点。测试条件随数据列出。

• 取样窗口 2026-10-12 至 10-26，有效样本 2880 次
• 节点覆盖 168 个，地区节点群 52 个，全部纳入统计
• 握手中位 79 毫秒，来自每节点 600 次压测采样
• 丢包中位 0.18%，来自晚高峰窗口 720 次加测统计
• 可用率 99.95%，按 2880 次心跳采样统计
• 客户端基线 v8.2.4，以官方构建记录核对