桌面端是功能最完整的组件,也是进程指纹识别与诊断面板的唯一载体。它承担全部本地判定工作:识别进程、匹配规则、决定通道,并把判断依据写进诊断记录。
支持 Windows 10 1809 及以上与 macOS 12 及以上。安装过程会自动替换旧版网络组件,不需要用户手工处理驱动或虚拟网卡;卸载时会一并清理残留的虚拟网卡与路由项。
移动端的判定粒度以应用为单位,而不是进程。原因很直接:移动系统不允许读取其他应用的可执行文件信息,所以移动端用「应用标识 + 域名规则」组合替代进程指纹,效果接近,但不会声称是完全相同的机制。
移动端最需要注意的是网络切换:从 Wi-Fi 切到蜂窝时,如果沿用原节点会出现一段时间的卡顿。客户端会在检测到网络变化后重建会话,并把这次切换记录在诊断信息里。
选型不需要把所有组件都装上。先确定必须覆盖的设备,再确定需不需要进程级精度,这两个答案组合起来就只剩一种推荐配置。
| 你的情况 | 推荐组合 | 不要这样做 |
|---|---|---|
| 只有一台电脑,需要按应用精细控制 | 桌面端客户端 | 不要用路由器插件替代,插件看不到进程 |
| 手机平板为主 | 移动端客户端 | 不要期待移动端有进程级分流 |
| 有电视、游戏主机 | 桌面端 + 路由器插件 | 不要让同一台已装客户端的设备再走插件 |
| 需要固定出口 IP | 带固定出口的档位 + 桌面端 | 不要依赖动态节点做固定出口业务 |
不是。叠加覆盖会造成同一条连接被处理两次,反而增加开销。覆盖与精度按需取舍。
不能。插件按域名与地址段分流,无法识别进程,精度天然低于桌面端。
不是必须,但排查问题时它能省大量时间,并且可以独立运行,不需要完整客户端。
下列示意图对应本页讲解的关键结构,建议结合正文一起看,读图要点已写在图注中。

配置耗时对比:手工填写与自动识别
网络拓扑:终端判定 + 双通道出口路由器插件解决「设备装不了客户端」的问题,例如电视、游戏主机、以及部分办公打印机。它运行在路由器上,按域名与地址段分流,不支持进程级识别——路由器看不到终端上的进程,这是能力边界而不是配置问题。
插件对固件有要求:需要支持安装第三方软件包的固件,且可用存储不低于 32MB、内存不低于 256MB。不满足时可以退而使用「客户端 + 热点共享」的方式获得相近效果。
| 项目 | 要求 | 说明 |
|---|---|---|
| 固件类型 | 支持软件包安装的固件 | 原厂精简固件通常无法安装 |
| 可用存储 | ≥ 32MB | 用于存放插件与规则库 |
| 内存 | ≥ 256MB | 规则库驻留与并发连接需要 |
| 分流粒度 | 域名 / 地址段 | 不支持进程级 |
规则库是五个组件共用的分类依据,也是唯一独立于客户端版本更新的组件。它的质量决定了自动识别的准确率:规则越准确,用户需要手工干预的次数越少。
规则库包含三类条目:进程条目(应用身份)、域名条目(服务分类)、地址段条目(无域名流量的兜底)。每条规则都带有来源与更新时间,便于回溯「某次分流变化是不是规则库导致的」。
诊断工具可以独立运行,不需要安装完整客户端。它的作用是在排查问题时把「现象」变成「可判断的证据」:当前系统有哪些网络组件、规则库版本与判定是否生效、常见配置冲突、以及需要提交给支持团队的日志包。
工具默认只做只读检查,不修改系统设置。若需要生成日志包,会明确列出包含的文件清单,其中不包含访问内容。
五个组件不是并列的五个产品,而是有明确依赖关系的一套系统。理解依赖关系可以避免「装了插件还是没生效」这类误会。
| 组件 | 依赖 | 被谁依赖 |
|---|---|---|
| 分流规则库 | 无 | 所有组件 |
| 桌面端客户端 | 规则库 | 运行它的终端 |
| 移动端客户端 | 规则库 | 运行它的终端 |
| 路由器插件 | 规则库、账号授权 | 接入路由器的设备 |
| 诊断工具 | 无(可独立运行) | 排查流程 |
规则库是所有组件的前提:如果规则库版本过旧,无论客户端多新,分类准确率都会下降。
只装桌面端,覆盖的是一台电脑;加上路由器插件,覆盖范围扩展到全屋设备,但粒度从进程降到域名。组合的价值在于覆盖,不在于提高精度。
当前主线版本为 v5.1,规则库版本独立编号。客户端与规则库必须同时满足最低版本要求,否则新分类条目可能无法识别。
| 平台 | 最低系统 | 进程级分流 | 诊断面板 |
|---|---|---|---|
| Windows | Windows 10 1809 | 支持 | 支持 |
| macOS | macOS 12 | 支持 | 支持 |
| Android | Android 9 | 不支持(按应用) | 简化视图 |
| iOS | iOS 14 | 不支持(按应用) | 简化视图 |
| 路由器插件 | 见固件要求 | 不支持 | 命令行输出 |
部署插件前先做一次环境核对,能省掉大部分安装失败。最常见的失败原因是存储空间不足与原厂固件不允许安装软件包。
规则库更新是增量下发,只传输发生变化的条目,不重新下载全量数据。更新只改分类,不改程序,因此不会触发系统级变更,也不需要重启。
更新后客户端会展示本次变更的条目数与影响范围。若发现某应用分流异常,可先在设置中回滚规则库;如果回滚后恢复正常,基本可以确定是分类变化导致的,可直接提交反馈。
诊断工具的输出分三块:环境、判定、日志。环境块回答「系统里有什么」;判定块回答「这条流量被怎么判的」;日志块用于提交给支持团队。
| 区块 | 内容 | 是否含敏感信息 |
|---|---|---|
| 环境 | 网络组件版本、虚拟网卡状态、系统版本 | 否 |
| 判定 | 目标、命中规则、通道、耗时 | 不含访问内容 |
| 日志 | 连接元信息与错误码 | 不含访问内容 |
提交日志包前,工具会列出打包清单,确认后再上传,避免把无关文件带出去。
账号按席位授权,一个席位同一时间只能在一台设备上建立加速会话。超出席位时,先登录的设备会被挤下线,这是有意为之:不允许多台设备共用同一席位,否则节点资源会被少数账号占满。
设备数量较多的场景建议使用团队版,按成员分配席位并支持集中查看使用情况。需要说明的是,团队版提供的是席位管理,不是流量审计——客户端不做明文审计。
在企业内网使用时,最容易出问题的是与内网代理、终端安全软件的叠加。正确的做法是先把企业代理与内网域名加入直连规则,再开启加速,而不是反过来。
选型只需要回答两个问题:需要覆盖哪些设备,需不需要进程级精度。答案组合决定组件组合。
不确定时,先只用桌面端跑一周,把诊断面板中的「判定依据」看一遍,再决定是否需要扩大覆盖。
配置耗时对比:手工填写与自动识别
网络拓扑:终端判定 + 双通道出口