多跳中继拓扑设计与流量分流原理 • Liu Yang's Blog

多跳中继在游戏加速、跨数据中心访问、远程接入私有网络等场景下都有应用。本文从拓扑和原理角度整理设计思路，不涉及具体工具配置。

多跳链路的核心思路

多跳转发的基本模型：每一跳只负责转发，末端节点负责最终的连接和加密，中间节点不感知上层协议内容。

客户端 → 入口节点 → 中继节点 A → 中继节点 B → 出口节点 → 目标服务

这个设计的好处是各段可以独立替换——换一条线路或一个中继节点，其余部分不受影响。

国内 BGP 入口  ↔  IEPL 专线段  ↔  东京中继  ↔  西雅图出口

用户连接国内入口，账号信息和出站协议由西雅图出口定义，中间两跳只做端口转发。任何一段出问题，只需替换那一跳，其他不动。

国内入口的质量直接影响整条链路的延迟基准，常见方案：

实测中，商业加速器的北京入口往往比自建方案的 9929 骨干入口低 5ms 左右，这是自建方案在欧美区域难以弥补的劣势。

分流的本质是：根据规则集，将流量路由到不同的出站路径。规则可以基于：

分流规则可以工作在客户端（用户设备上的代理软件）或服务端（中继节点上），两者可以叠加使用。

客户端分流的出站节点多，规则需要覆盖日常所有流量场景。典型的分组策略：

规则集通常从远端订阅获取（包含域名列表、IP 段等），按优先级依次匹配，未命中规则的流量走默认出站。

分流的执行顺序很重要：私有 IP 直连 → DNS 劫持 → 域名规则 → IP 规则 → 最终默认出站。顺序错误会导致 DNS 泄露或规则失效。

服务端分流常见于落地节点需要进一步选择出站的场景，规则相对简单：

基于 DNS 的分流：对特定域名指定不同的 DNS 服务器，让解析结果指向对应地区的服务器。优点是不改变流量路径，只影响 DNS 解析。

基于出站节点的分流：开启流量嗅探，识别目标域名后将流量转发到指定的下一跳节点。适合落地节点需要做地区解锁的场景（例如落地在香港，将特定流量转发到新加坡节点解锁）。

系统代理只能覆盖支持 HTTP/SOCKS 的应用，游戏客户端、命令行工具等通常不走系统代理。透明代理通过在更底层接管流量来解决这个问题。

在操作系统中创建一张虚拟网卡，将系统路由表的默认路由指向它，从而接管所有 TCP 和 UDP 流量，再由代理程序按规则分发。

两种 DNS 模式：

另一种思路是在路由器层面做分流：在局域网中增加一台旁路由，内网设备只需修改默认网关，所有流量在旁路由上统一处理，客户端完全无感知。

优点：一次配置覆盖局域网所有设备。缺点：旁路由会引入额外一跳的延迟，对 FPS 游戏有轻微影响。

入口层（接收用户流量）→ 中继层（转发，不解密）→ 出口层（连接目标，定义出站协议）

中间节点不解密的好处：降低单节点的计算压力，且出站加密方式可以统一由出口节点控制。

每一跳都会增加：

实践中，3 跳以内体验较好。超过 4 跳后，边际延迟收益通常无法弥补额外的复杂度和故障概率。

整条链路的每一跳都必须支持 UDP 透传，否则游戏流量会在中间断掉。

核心原则：稳定性 > 延迟 > 封装复杂度。线路本身的质量是游戏体验的决定因素，封装方式的差异通常只有 1ms 量级的影响。