快连隧道拆分：规则怎么写、怎么验、怎么排错

快连隧道拆分：规则怎么写、怎么验

我们做过一次内部复盘，把过去两年收到的"抱怨类"工单重新分类。结果出乎意料：真正因为"带宽不够"导致的投诉不到两成，超过六成的真实原因是绕行——本来该直连的国内服务，被一股脑塞进了海外加速通道，白白多走了几千公里。隧道拆分解决的就是这件事，而且它不是"优化项"，是架构问题。

快连一、绕行的代价：先算一笔账

当一个客户端只有"全量代理"这一种模式时，所有流量都必须经过远端节点。国内政务系统、银行 App、企业 OA、视频网站，本来在本地机房或同城 IDC 就能完成握手，却要先出境再回来。我们实测过一条典型路径：上海用户访问上海的政务服务平台，全量代理下请求要经香港节点绕行一圈，握手时间从直连的 0.6 秒涨到 2.4 秒——四倍。这不是网络质量差，这是路线选错了。

更隐蔽的代价在实时场景里。用户开视频会议的时候，同时挂着国内 OA 的心跳请求，两者共用同一条加速隧道，OA 的轮询流量会在拥塞时抢占实时业务的队列位置。会议室里感受到的是画面偶尔一抖，但根因在完全不相干的另一个应用上。这类问题排查起来极其耗时，因为用户的第一反应永远是"是不是节点不行"。

快连二、拆分什么：三级识别引擎

隧道拆分的核心是"这条流量该走哪条隧道"的判断，我们把判断拆成三级，逐级精细化，优先级由低到高。

第一级是目标地址。这是最粗也最快的判断。我们维护一份持续更新的目标地址库，覆盖国内主要政务、金融、公共服务与企业常用域名段。命中即直连，不进入任何加速隧道。这一级能覆盖大约七成的国内流量，开销几乎为零。

第二级是 TLS SNI 识别。有些服务使用 CDN，同一个 IP 上同时承载国内外站点，仅靠地址无法区分。这时我们在 TLS 握手的 ClientHello 阶段读取 SNI 字段，拿到真实的目标域名再判断。由于读取发生在握手早期，不会对连接时延造成可感知的影响。

第三级是进程指纹。最典型的难题是"同一域名下的不同应用"——企业微信与微信共用大量域名，但企业微信里的审批流与微信里的视频号，优先级完全不同。这时我们基于发起连接的进程特征（可执行文件签名、进程路径、父子进程关系）做识别，把判断精度提到应用粒度。

快连三、双隧道架构：一条直连、一条加速

识别完成后，客户端维护两条逻辑隧道：直连隧道与加速隧道。直连隧道的本质是"不做任何事"——流量按系统原生路由出去，不封装、不转发、零额外开销。加速隧道才走我们优化的海外线路。这个设计的关键在于两条隧道在同一个客户端进程内共存，不需要软路由、旁路由或第二台设备。

快连四、落地细节：策略路由与连接跟踪

在 Linux 与 macOS 上，双隧道通过策略路由（policy routing）实现：为加速隧道单独建立一张路由表，用 ip rule 把标记过的流量导向该表，直连流量走主表。标记动作发生在连接建立的第一时间，基于前面三级识别的结果。

难点在连接跟踪（conntrack）。同一个应用可能先建立一条国内连接、再建立一条海外连接，如果没有把标记与连接状态绑定，就会出现"后半段流量走错隧道"的问题。我们的做法是把分流标记写进连接跟踪条目，让同一条连接的后续数据包沿用首次判定，避免中途改道导致的重传。

快连五、TLS SNI 识别的边界与应对

我们必须诚实地说明 SNI 识别的局限：随着 ECH（Encrypted Client Hello）逐步铺开，SNI 字段会被加密，这条识别路径在部分站点上会失效。我们的应对是三重兜底：一是优先使用进程指纹，它不依赖网络层信息；二是对已知使用 ECH 的服务预先维护地址与进程映射；三是提供手动规则入口，把最终判断权交给用户。

同样需要说明的是，我们不做深度包检测（DPI）。DPI 意味着解析应用层内容，这与我们的无日志承诺在根本上冲突。我们只读取握手阶段的元数据，不触碰载荷。

快连六、实测：分流前后差多少

第三项指标常被忽略但很重要：开启隧道拆分后，国内流量在物理路径上完全没有出境，也就没有了跨境链路的不确定性与合规风险。对跨国企业来说，这一点往往比速度更有价值——跨境数据传输需要走合规路径，而不必要的出境本身就是风险。

快连七、常见误配置与排查

如果你希望按自己的使用习惯做一次针对性配置，建议先连续观察一天的分流诊断面板——它会列出每个应用的判定结果与实际走线，据此调整比凭猜测改规则要可靠得多。