当我们讨论 Tailscale 的网络连接建立过程时，UDP 打洞（UDP hole punching）失败后的中继回退机制是一个关键技术点。与传统 VPN 集中式路由不同，Tailscale 的设计哲学是优先建立端到端的直接连接，只有在 NAT 或防火墙阻止直接通信时才降级到 DERP 中继服务器。理解这一状态机的工作原理，对于诊断连接问题、优化网络拓扑以及在特殊网络环境下进行工程化配置都具有重要价值。
连接建立的核心流程与状态迁移
Tailscale 客户端在建立任意两个节点之间的连接时，遵循一个明确的状态迁移流程。每个新连接实际上都从 DERP 中继开始，这一设计并非偶然。DERP 服务器承担着关键的握手协调功能：它帮助双方交换各自的观察端点信息（observed IP 地址和端口）以及加密密钥，随后双方并行尝试建立直接的 UDP 连接。这个初始阶段可以理解为一种 “竞赛” 机制 —— 直接路径和回退路径同时被探测，客户端会迅速评估哪条路径可用并选择最优者。
当 UDP 打洞成功时，流量会无缝切换到直接的 UDP 路径，用户通常不会察觉到这一切换过程。这种设计的优势在于延迟极低、吞吐量高，且所有流量都在端到端加密的 WireGuard 隧道中传输，不经过任何中央服务器。然而，当 UDP 打洞始终无法成功时，流量将继续通过 DERP 传输，直到网络条件发生变化。根据 Tailscale 官方博客披露的数据，在典型网络环境下，直接连接的建立成功率超过百分之九十，这意味着绝大多数场景下流量都能绕过中继服务器。
理解这一状态机的关键在于认识到它是一个被动检测过程而非主动超时过程。Tailscale 客户端并不会预先设定一个 “打洞超时” 然后强制切换到 DERP；相反，它会持续尝试打洞，一旦检测到直接路径可用就立即切换。这种设计的好处是灵活性极高，即使在网络条件短暂变化（如 NAT 映射过期后重新建立）的情况下，连接也能自动升级到更优路径。
UDP 穿透失败的典型场景与检测机制
UDP 打洞失败并非随机发生，而是与特定的网络环境特征密切相关。理解这些失败模式有助于我们更好地设计监控策略和故障排查流程。
对称 NAT（Symmetric NAT）是最主要的失败原因。这类 NAT 设备为每个 outbound 连接分配不同的外部端口，导致打洞所需的端口预测变得不可能。即使双方使用 STUN 协议进行协调，也无法建立稳定的映射关系。企业级防火墙和运营商级 NAT 网关通常采用这种行为，以最大化连接隔离。在两个对称 NAT 之间的连接几乎必然需要通过 DERP 中继。
多层 NAT（Double NAT 或 Multiple NAT）显著增加了打洞复杂度。当数据包经过多个 NAT 层时，每层的行为都需要正确协调才能成功打洞。例如，一台笔记本通过酒店 WiFi 的 NAT 连接到互联网，再通过云 VPC 的 NAT 网关，这种多层转发大幅降低了直接连接的成功概率。
严格防火墙策略是另一个常见障碍。某些企业网络或安全设备会直接阻断所有未经请求的 UDP 流量，甚至将 P2P 连接尝试归类为可疑行为。UniFi 安全网关默认会将 P2P 流量视为威胁并阻止，除非用户手动禁用该规则。在这些环境中，Tailscale 的 UDP 探测包根本无法到达对端，因此永远无法建立直接连接。
值得强调的是，Tailscale 的检测机制是实时的、持续运行的。当 UDP 包无法穿透时，客户端不会收到任何错误响应 —— 它只是看不到任何返回流量。这种 “沉默失败” 意味着状态机必须依赖超时或对端确认来判定打洞是否成功。
状态机的触发条件与可配置参数
需要明确的是，截至目前 Tailscale 官方并未暴露用户可调节的 “UDP 打洞超时” 或 “DERP 回退超时” 参数。这些检测和回退逻辑被内置在客户端内部，由控制平面协调。客户端代码中的超时值和重试模式属于实现细节，可能随版本更新而变化。
尽管无法直接调节超时参数，工程师仍有其他方式影响状态机行为。首先是网络环境的优化：调整防火墙和 NAT 配置，使其更加友好地支持端点独立映射（Endpoint-Independent Mapping）。例如，在某些防火墙设备上增加 “最大 UDP 会话数” 可以容纳更多的并发打洞尝试。其次是拓扑设计：在网络中部署稳定的 UDP 端口暴露节点，或配置特定的节点作为对等中继（Peer Relay），可以为其他设备提供更可靠的目标，减少对 DERP 的依赖。
诊断工具在这一过程中扮演着重要角色。tailscale netcheck 命令可以检查节点当前的 NAT 类型、打洞状态以及是否在使用 DERP。tailscale ping 则可以显示当前路径是直接连接还是经由 DERP 或对等中继。这些工具虽然不能直接控制超时参数，但可以帮助工程师理解当前的网络状态，从而做出正确的拓扑调整决策。
监控指标与工程实践建议
在实际生产环境中，建议通过以下方式监控连接状态。首先关注 DERP 使用率这一核心指标：如果某个节点的 DERP 流量占比异常升高，通常意味着该节点所在网络环境存在打洞困难，可能是对称 NAT、严格防火墙或运营商级 NAT 导致的。其次监控连接切换事件，理想情况下一个稳定的长连接应该在建立后保持在直接路径上，频繁的路径切换可能暗示网络不稳定或 NAT 映射生命周期过短。
对于必须确保低延迟的场景，可以考虑在关键节点之间部署专线或 WireGuard 直连通道，绕过 Tailscale 的打洞机制。在某些合规要求严格的企业内部网络中，完全禁用 UDP 并强制使用 TCP/443 端口可能是更稳妥的选择，尽管这意味着完全放弃直接连接的优势。
最后需要认识到，Tailscale 的状态机设计本身就是为了适应复杂多变的网络环境。即使无法直接调节超时参数，理解其工作原理并配合适当的环境优化和监控手段，已经足以应对绝大多数工程挑战。
参考资料
- Tailscale 官方博客：NAT traversal, and how we're improving it (pt. 1) – https://tailscale.com/blog/nat-traversal-improvements-pt-1