Tailscale 直连失败后，流量如何切换至 DERP 中继并加密传输？
Tailscale 中继服务器 DERP 是直连失败时的备用转发机制，负责在 UDP 通道断裂时加密中转流量并协助节点交换端点信息。
Tailscale 连接核心逻辑：为什么坚持“直连优先”策略
Tailscale 坚持直连优先策略，旨在利用 WireGuard 构建低延迟的端到端加密通道，仅在路径彻底不可用时才启用中继转发。
设备间通信时，Tailscale 默认构建的是端到端加密的 WireGuard 直连通道。只有当这条路径彻底断裂或无法维持，流量才会被引导至 DERP 中继机制进行转发[1][2]。这种设计并非技术妥协，而是基于性能与架构的最优解。
WireGuard 直连的理想场景
在理想网络环境下，P2P 直连能带来极低的延迟和最高的吞吐量。数据无需经过第三方节点中转，就像两人直接通话，中间没有电话总机转接的等待。这种模式高度依赖公网 IP 的存在以及端口映射的稳定性。只要双方处于 Easy NAT 环境，STUN 服务就能协助发现稳定的公网地址，让两端直接握手建立 UDP 隧道[3]。
引入中继方案作为兜底，而非首选，是因为任何额外的跳点都会增加延迟并消耗服务器带宽。Tailscale 的逻辑很清晰：先利用 DERP 交换密钥与端点信息，并行尝试 UDP NAT 穿透；一旦成功，立即切断中继链路，回归直连；若失败，才继续经由中继传输加密流量[1][2]。甚至在无直连路径时，系统也会优先寻找 tailnet 内配置的 peer relay，仅在缺乏可用对等节点时才回退到公共集群[1]。
这里存在一个常见的认知误区：许多人认为 DERP 只是用来“搬运数据”的管道，实际上它在连接建立阶段就扮演了至关重要的“信令枢纽”角色。即便最终未能打通直连，DERP 也必须在数据传输前完成双方的身份认证和密钥协商。如果剥离了这个信令交换过程，中继服务器就无法知道该将加密包发给谁，也无法验证接收方的合法性。因此，DERP 不仅仅是备用通道，更是整个 P2P 握手协议中不可或缺的协调者。
当直连失效：Tailscale 中继服务器 DERP 工作原理详解
当设备间 UDP 直连通道彻底断裂，系统会触发严格判定序列自动切换至 DERP 中继服务器，确保通信任务迅速接管且不中断。
当设备间的 UDP 直连通道彻底断裂，流量并未中断，而是自动切换至中继服务器进行转发。[1][2] 这种切换并非盲目发生，系统内部有一套严格的触发判定与回退序列，确保在直连不可用时迅速接管通信任务。
Peer Relay 与 DER P的回退优先级
系统在处理连接请求时，遵循“先内后外”的优先级逻辑。首先，节点会检查 Tailnet 网络内是否配置了专用的 peer relay 服务器。如果存在可用的 peer relay，流量将优先通过该私有节点进行中转。只有当网络环境中缺少可用的 peer relay，或者私有中继无法连通时，系统才会启动回退机制，转向公共 DERP 服务器集群。[1]
这种分层设计避免了所有流量无差别地涌向公共基础设施。私有 peer relay 通常部署在更靠近用户或企业数据中心的位置，能提供更低延迟的中转路径；而公共 DERP 则作为兜底方案，覆盖全球各地的接入点，确保在任何极端网络环境下都有路可走。
| 层级 | 目标对象 | 触发条件 | 适用场景 |
|---|---|---|---|
| 第一级 | 私有 Peer Relay | Tailnet 内已配置且可用 | 企业自建、低延迟需求 |
| 第二级 | 公共 DERP 服务器 | 无可用 Peer Relay | 个人用户、无自建中继环境 |
| 第三级 | 直连 UDP | NAT 穿透成功 | 理想网络环境（非本节重点） |
表格清晰地展示了流量的流向逻辑。系统不会直接跳过私有中继去连接公共 DERP，而是像接力赛一样，一层层尝试直到找到可用路径。[1]
NAT 穿透失败后的信令交互
一旦确定需要中继，节点便进入信令交互阶段。DERP 服务器在此刻充当“中间人”的角色，负责交换端点信息和密钥材料。节点向 DERP 发送包含自身公网 IP 和端口信息的信令，同时接收对端的同类信息。[1][2]
值得注意的是，这个交换过程是并行进行的。节点在利用 DERP 获取对方地址的同时，依然会持续尝试 UDP NAT 穿透。这就像一边派人去对面送地图（通过 DERP），一边自己拿着地图继续尝试翻墙（UDP 穿透）。如果穿透成功，双方立即建立 WireGuard 直连，流量不再经过 DERP；若穿透失败，加密数据流则完全依赖 DERP 服务器进行转发。[1][2]
这种并行策略最大限度地利用了网络机会。即便最终必须使用中继，前期的信令交换也已完成了身份验证与密钥协商，确保了传输链路的完整性。整个流程环环相扣，既保证了连接的稳定性，又维持了端到端的加密特性。
为了看清两种方案在组件定义上的区别，我们可以对比它们在 NAT 穿透失败后的处理逻辑：
| 对比维度 | Tailscale 单一 DERP 架构 | NetBird 分离式组件架构 |
|---|---|---|
| 核心组件 | 统一 DERP 服务器（含信令与中继） | 独立 Management、Signal、Relay 组件 |
| 信令交互 | 通过 DERP 节点交换密钥与端点信息 | 通过 Signal 组件协调连接状态 |
| 数据转发 | 直接由 DERP 节点执行加密转发 | 由专用 Relay 节点处理流量透传 |
| 部署形态 | 单点集成，配置相对集中 | 多点分布，需分别维护各组件 |
| 安全边界 | 端到端加密贯穿始终，中继不可见 | 同样保持端到端加密，依赖组件隔离 |
[4]
必须承认，单纯从组件划分的角度，很难断定哪种方案在特定网络下更优。现有材料缺乏统一的测试样本和量化指标，无法盲目断言谁拥有更高的直连率或更低的延迟。[2][3] 无论架构如何拆分，只要遵循 WireGuard 的加密标准，数据在穿越 DERP 中继时依然是安全的。
加密数据如何在 DERP 中继中安全传输
在 DERP 中继传输中，数据包被封装进新的加密信封由节点搬运，DERP 仅负责转发而无法解密或篡改始终维持端到端安全逻辑。
当 UDP 直连彻底失效，数据包不会裸露在公网裸奔，而是被塞进一层新的信封，通过 DERP 服务器中转。[1] 这个过程看似多绕了一站，但核心的安全逻辑从未改变：Tailscale 依然维持端到端加密，DERP 节点只负责搬运，看不懂内容，也改不了数据。[2]
具体流程像是一个严密的物流系统。源设备将 WireGuard 加密后的原始报文，再次封装成 HTTPS 请求或 WebSocket 帧，发给最近的 DERP 服务器。DERP 收到后，依据内部路由表找到目标设备的地址，将这份“加密封装包”原样转发过去。目标设备收到后，剥开外层协议，直接拿到内层的 WireGuard 密文进行解密。[1] 中间经过的每一跳，对第三方而言都是一堆乱码。即使有人窃取了 DERP 服务器的流量，拿到的也只是无意义的加密负载，无法还原出真实的通信内容。
为了看清两种方案在组件定义上的区别，我们可以对比它们在 NAT 穿透失败后的处理逻辑：
| 对比维度 | Tailscale 单一 DERP 架构 | NetBird 分离式组件架构 |
|---|---|---|
| 核心组件 | 统一 DERP 服务器（含信令与中继） | 独立 Management、Signal、Relay 组件 |
| 信令交互 | 通过 DERP 节点交换密钥与端点信息 | 通过 Signal 组件协调连接状态 |
| 数据转发 | 直接由 DERP 节点执行加密转发 | 由专用 Relay 节点处理流量透传 |
| 部署形态 | 单点集成，配置相对集中 | 多点分布，需分别维护各组件 |
| 安全边界 | 端到端加密贯穿始终，中继不可见 | 同样保持端到端加密，依赖组件隔离 |
[4]
必须承认，单纯从组件划分的角度，很难断定哪种方案在特定网络下更优。现有材料缺乏统一的测试样本和量化指标，无法盲目断言谁拥有更高的直连率或更低的延迟。[2][3] 无论架构如何拆分，只要遵循 WireGuard 的加密标准，数据在穿越 DERP 中继时依然是安全的。
真实环境下的限制：对称 NAT 与企业防火墙的影响
对称 NAT、双重 NAT 及企业防火墙会切断直连路径，强制流量回退至 DERP 中继机制，因为 STUN 无法在这些复杂环境中发现稳定映射。
当设备处于对称 NAT、双重 NAT 或企业防火墙背后时，直连路径往往被彻底切断。这些场景下，流量必须强制回退至 Tailscale 中继服务器转发逻辑，即使用 DERP 中继机制。[3] 厂商文档中提到的”Easy NAT”或 EIM 条件，仅指代 STUN 能发现稳定公网 IP 与端口映射的特定情形，无法覆盖上述复杂网络环境[3]。
复杂网络环境中的连接挑战
企业防火墙通常实施严格的端口受限过滤，移动网络切换则会导致 IP 地址频繁变动。在对称 NAT 机制下，外部请求到达的端口与内部发出的端口不一致，STUN 探测到的映射对接收方无效。这种结构性阻碍让 P2P 握手彻底失效。此时，中继不再是备选方案，而是唯一可行的数据通道。
现有公开材料并未提供统一测试数据来量化不同方案在这些极端条件下的表现[2][3]。缺乏标准化的网络样本、成功率定义及吞吐量分位数，使得盲目比较 Tailscale 与其他方案的优劣失去依据。技术选型不应基于未经证实的假设，而应正视这些物理层面的连接限制。
针对经常遇到此类复杂网络环境的用户，一个切实可行的优化建议是：在企业出口网关或关键办公区部署自建的 DERP 服务器。与其依赖公共 DERP 节点可能存在的跨国拥堵，不如将中继节点部署在与员工终端同一局域网或邻近机房的环境中。这样即使无法实现 P2P 直连，也能将中继跳数控制在最小范围内，显著降低因绕行公网带来的延迟抖动。这一步操作不需要复杂的网络改造，只需在现有服务器上运行 Tailscale 的 DERP 二进制文件并配置为私有中继即可，对于提升远程协作体验有立竿见影的效果。
FAQ: 关于 DERP 中继的常见疑问
Q: 开启 DERP 中继会影响我的网络安全吗？ A: 不会。即使在必须使用中继的情况下，数据流依然经过 WireGuard 加密。DERP 服务器只能看到加密后的数据包，无法解密内容，因此安全性与直连模式保持一致。
Q: 为什么有时候连接速度会变慢？ A: 当网络环境允许直连时，延迟最低。一旦触发 Tailscale 回退逻辑，流量需要经过 DERP 服务器中转，物理距离的增加和额外的加密/解封装步骤自然会带来轻微延迟，这是为了保障连通性所必须付出的代价。
Q: 我可以自己搭建 DERP 服务器吗？ A: 可以。对于企业用户，部署私有的 peer relay 或自定义 DERP 节点是优化中继机制的有效手段，能够显著降低跨地域访问的延迟。
参考来源
- DERP servers · Tailscale Docs · https://tailscale.com/docs/reference/derp-servers（S级）
- How Tailscale is improving NAT traversal (part 1) · https://tailscale.com/blog/nat-traversal-improvements-pt-1（S级）
- Understanding NAT and Connectivity - NetBird Docs · https://docs.netbird.io/about-netbird/understanding-nat-and-connectivity（S级）
- Implementing Zero Trust with NetBird - NetBird Docs · https://docs.netbird.io/use-cases/security/implement-zero-trust（S级）