从识别到落地的完整链路
一条连接从发起到建立，快连要在几毫秒内完成五件事。这条链路的每一步都可以在诊断面板里看到结果，不存在「黑箱判断」。
- 采集：在网络层标记出站连接，获取进程标识与目标域名。
- 指纹：对已登记进程计算路径、签名与哈希指纹。
- 分类：按三级识别引擎给出分类结论。
- 决策：按优先级选出通道，并挑选候选节点。
- 隧道：在加速通道内建立私有协议会话，或走直连通道。
整个过程不解析应用层报文内容，也不做 TLS 解密：域名来自握手阶段的公开字段。
采集：只看必要字段
采集阶段的原则是最小必要：只取判定所需的字段，不取内容。具体来说，需要的是发起进程、目标域名、目标地址与端口，以及连接建立的时间点。
这些字段都在网络层可见，不需要解密。采集结果用于当次判定，除诊断面板开启时写入的元信息外不落盘；诊断记录默认保留 7 天并可关闭。
「不做中间人解密」是一条硬边界。任何要求明文审计的场景，都不适合用这套方案，应该改用企业级网关。
复现一次分流判定：四步验证法
想确认「系统真的按说明在工作」，不要只看能不能打开网页，而是按下面四步把一次判定的输入、依据、结果、开销都看清楚。
- 选一个目标：挑一个平时体感最明显的应用或目标，避免用无关紧要的域名做验证。
- 触发一次连接：打开该应用并触发一次真实请求，让它出现在诊断面板中。
- 读四个字段：看「判定依据」确认命中层级，看「通道」确认走向，看「首包时间」判断链路，看「重试次数」判断稳定性。
- 做对照实验：把该目标加入用户规则强制直连，再观察同样字段的变化，两次对照就能确认分流是否生效。
对照实验是判断分流是否生效最可靠的方法：只要强制直连与自动判定的字段出现差异，就说明判定链路在工作。
四级判定与可观察现象
| 判定层级 | 「判定依据」显示 | 典型可观察现象 |
|---|---|---|
| 进程指纹命中 | 进程 | 同一域名下的两个应用可以走向不同通道 |
| 域名规则命中 | 域名 | 服务整体走向一致，域名变更后判定会随之变化 |
| 地址段兜底 | 地址段 | 无域名的直连 IP 流量也能被归类 |
| 三级均未命中 | 默认 | 该目标按默认路由处理，建议补充规则 |
为什么不能只看「有没有变快」？
因为变快可能来自节点变化而非分流正确。判定依据与通道才是分流的直接证据。
对照实验会不会影响正常使用？
会临时改变该目标的走向，验证完删除用户规则即可恢复，不影响其他规则。
「默认」很多说明什么？
说明规则库覆盖不足。此时应补充规则，而不是把默认行为改成全部加速。
配图与读法
下列示意图对应本页讲解的关键结构，建议结合正文一起看，读图要点已写在图注中。
分流判定时序：从采集、指纹、分类到隧道建立。读图要点：判定发生在连接建立之前，因此不需要解密报文内容。
双通道出口与客户端内部结构概览。读图要点：直连通道不封装、不转发，与加速通道相互独立。
配置耗时对比：手工填写与自动识别
网络拓扑：终端判定 + 双通道出口指纹：进程签名与哈希
进程指纹的作用是给「哪个应用」一个稳定标识。路径会随安装位置变化，文件哈希会随版本升级变化，所以三者结合才能既稳定又能防替换。
| 要素 | 读取内容 | 作用 |
|---|---|---|
| 规范路径 | 可执行文件的绝对路径 | 日常匹配，速度最快 |
| 签名主体 | 数字签名中的主体信息与校验状态 | 跨版本稳定识别 |
| 文件哈希 | 已登记文件的摘要值 | 识别文件是否被替换 |
未登记进程不会被拒绝，只是退回按域名判定，并在诊断面板中标出「未登记」。这保证了新应用不会因为规则库未收录而不可用。
分类：三级识别的递进关系
三级的顺序不可调换。先用进程缩小范围，再用域名确定分类，最后用地址段兜底，每一级都为下一级减少不确定性。
- 进程级命中时，直接得到应用身份，判定最精确
- 进程级未命中时，域名规则给出服务分类
- 两者都未命中时，地址段规则给出地理兜底
- 三级都未命中，按默认路由处理，并在面板中标记为「默认」
实践中，「默认」比例是衡量规则库质量的好指标：比例高说明规则覆盖不足，应优先补充规则而不是调整默认行为。
路由决策：候选路径与打分
分类只决定「走不走加速」，选哪个节点是另一层决策。客户端会先按地理与时延筛出若干候选，再按历史成功率、当前往返时延、负载水位三项打分，取分数最高的一条。
打分是动态的：同一节点在不同时段可能被选中的概率不同。若候选全部劣化，客户端会降级到保底节点，并在诊断面板标出「降级」，而不是直接断开连接。
3 项打分维度
动态候选池更新
保底降级路径
可查决策依据留痕
隧道：私有协议与认证加密
加速通道使用自研私有通讯协议，配合超群数据加密。选私有协议而不是直接套用通用方案，主要考虑两点：报文的可识别特征更低，以及可以做更贴合链路的拥塞控制。
加密层采用认证加密算法，同时保证机密性与完整性；握手阶段完成双向身份校验，会话密钥定期轮换以提供前向安全。序号与随机数参与校验，历史报文无法重放。
- 机密性：隧道内数据不可被读取
- 完整性：篡改可被检测
- 抗重放：历史报文不可复用
- 前向安全：密钥轮换限制单次泄露影响
回退：失败时的降级顺序
任何一条链路都可能失败，关键是把失败处理成「用户感知不到的降级」而不是断线。快连的降级顺序是固定的：换节点 → 换协议形态 → 回退直连。
- 换节点：当前节点连续失败或时延超阈值时，切到候选池中的次优节点。
- 换协议形态：节点可达但会话建立失败时，切换协议形态重试。
- 回退直连：加速通道整体不可用时，把该流量回退为直连，保证业务不中断。
- 记录：每次降级都写入诊断面板，便于事后确认是否发生过切换。
回退直连意味着该流量失去加速效果，但避免了「因为加速不可用导致完全无法访问」这种更差的结果。
DNS 与泄漏防护
分流做得好，DNS 没跟上，一样会出问题：域名解析走的路径与后续连接不一致，会出现「用国内 DNS 解析海外域名，拿到就近但错误的地址」。快连的做法是让解析与连接走同一条策略。
- 判定为加速的域名，解析也按加速策略处理，避免解析结果与出口不匹配
- 支持加密 DNS，减少解析过程被篡改的可能
- 提供 DNS 泄漏自检项，在自检报告中直接给出结论
- 内网域名强制走本地解析，避免内网服务解析失败
UDP 与 TCP 的取舍
UDP 与 TCP 不是二选一，而是按场景选择。实时类业务（语音、游戏、视频会议）更适合 UDP，因为它不需要等待重传；文件传输与网页访问通常用 TCP 更稳。
| 场景 | 建议 | 原因 |
|---|---|---|
| 视频会议 / 语音 | UDP | 容忍丢包，不能容忍等待重传 |
| 在线游戏 | UDP | 延迟敏感，抖动影响体感 |
| 网页与大文件 | TCP | 需要可靠传输与有序交付 |
| 受限网络 | 按可用性回退 | UDP 被限制时自动改用可用形态 |
当网络对 UDP 有明显限制时，客户端会在多次失败后自动调整，用户不需要手工切换。
规则库的匹配数据结构
规则多了以后，匹配效率取决于数据结构而不是条数。三类规则各用各的结构，避免把所有规则塞进一张线性表。
- 域名：按标签反转后建前缀树，后缀匹配天然变成前缀匹配
- 地址段：按前缀长度分段索引，先查长前缀再查短前缀
- 进程：先用哈希过滤，再比对路径与签名，避免全量字符串比较
这样设计的结果是：规则从 300 条扩到 600 条时，单次判断耗时几乎不变。
性能开销的测量方式
测量方式决定了数字是否可信，所以这里写清口径。分流判断开销指从拿到连接信息到给出结论的时间，在本地测量，不含网络往返；加速开销指相对于直连的额外时延，必须注明起点与节点位置。
| 指标 | 测量位置 | 口径说明 |
|---|---|---|
| 判断开销 | 本地 | 不含网络往返，取多次采样的中位数 |
| 首包时间 | 端到端 | 从发起连接到收到首个响应字节 |
| 额外时延 | 端到端 | 与同目标直连对比，注明节点距离档位 |
| 切换耗时 | 端到端 | 从检测到劣化到新通道可用 |
兼容性边界
有些环境天然不适合在网络层做处理，提前说明可以避免无效排查。
- 与其他网络层组件叠加时可能冲突，例如部分虚拟网卡与安全软件
- 需要中间人解密的环境不适用，客户端不做 TLS 解密
- 移动端受系统限制，无法做到与桌面端相同的进程级粒度
- 路由器插件的粒度受固件能力限制，通常只到域名与地址段
遇到冲突时的处理顺序是：先用诊断工具列出网络组件，再逐一排除，最后才考虑调整客户端配置。
常见技术误解
分流是不是就是按域名列白名单？
不是。域名只是三级识别中的一级，进程指纹负责区分应用，地址段负责兜底，三者顺序固定。
客户端会解密我的 HTTPS 流量吗？
不会。客户端不持有证书私钥，域名取自握手阶段的公开字段，不做中间人解密。
规则条数越多是不是越慢？
不是线性关系。域名走前缀树、地址段走分段索引，在 600 条量级下开销几乎不变。
为什么有时候判定结果是「默认」？
三级识别都未命中时按默认路由处理。默认比例偏高说明规则库覆盖不足，应补充规则而不是改默认行为。
切换节点会不会导致断线？
设计目标是不断线：降级顺序为换节点、换协议形态、最后才回退直连，每次降级都会记录在诊断面板。
配置耗时对比：手工填写与自动识别网络拓扑：终端判定 + 双通道出口