Tailscale Peer Relays 深度研究报告

2026-02-20 | 托尼

一、概述

Tailscale 于 2026 年 2 月宣布 Peer Relays 正式 GA（General Availability）。这是自 2025 年 10 月 Beta 发布以来的重大里程碑。

核心命题：当两台设备无法建立直接 P2P 连接时（受限于防火墙、NAT、云网络策略），Tailscale 过去只能依赖官方的 DERP 中继服务器。Peer Relays 允许你把自己 tailnet 中的任意节点变成高吞吐量中继，流量不再绕道 Tailscale 的公共基础设施。

简单说：从"借别人的路"变成"修自己的路"。

二、技术原理

2.1 Tailscale 连接的三种方式

类型	路径	性能	控制权
Direct (P2P)	设备 ↔ 设备	最优	N/A
DERP Relay	设备 → Tailscale DERP 服务器 → 设备	受限于 DERP 位置和带宽	Tailscale 控制
Peer Relay	设备 → 你的某个节点 → 设备	接近直连	你控制

2.2 Peer Relay 工作流程

1. 启用：在某个 Tailscale 节点上通过 CLI 开启 relay 功能

2. 发现：Relay 启动后向 DERP 发送 STUN 探测，获取自己的公网 IP:port

3. 广播：通过 Tailscale 控制平面向 tailnet 内其他节点广播自己作为 relay 的可用性

4. 转发：当两个节点无法直连时，流量经过 Peer Relay 转发

5. 安全：Relay 不解密流量，只转发加密数据包。只有同一 tailnet 内经过认证的节点才能使用

2.3 关键安全特性

端到端加密不变：Peer Relay 是个"盲转发器"，看不到明文
tailnet 内认证：外部主机无法使用你的 relay
ACL 控制：通过 grants 精确控制哪些设备可以使用哪些 relay

三、Peer Relay vs DERP：关键区别

维度	DERP	Peer Relay
部署方	Tailscale 官方（全球分布）	用户自己的节点
协议	TCP/HTTP (WebSocket)	UDP（原生 WireGuard）
吞吐量	受限，设计为可靠性优先	高吞吐，设计为性能优先
延迟	取决于最近的 DERP 节点位置	取决于你的 relay 位置（可以很近）
运维	零运维	需要自己管理节点
数据主权	流量经过 Tailscale 基础设施	流量留在你的基础设施内
适用场景	通用 fallback	高性能需求 / 受限网络

核心差异：DERP 用 TCP，Peer Relay 用 UDP。这意味着 Peer Relay 天然适合高吞吐、低延迟场景——UDP 没有 TCP 的队头阻塞和拥塞控制开销。官方博客直接说了：Peer Relay 的性能可以接近真正的 mesh 直连。

四、GA 版新特性（Beta → GA）

4.1 垂直扩展优化

锁竞争改进：每个 Peer Relay 上的包处理效率大幅提升
多 UDP socket 分散负载：流量不再挤在单个 socket
智能接口选择：客户端自动选择最优网络接口和地址族（IPv4/IPv6）
效果：多客户端并发中继时吞吐量显著提升

4.2 静态端点（Static Endpoints）

用 --relay-server-static-endpoints 手动指定固定 IP:port
解决的问题：在云环境中（AWS、GCP），实例在严格防火墙后面，自动端点发现失效
典型用法：把 Peer Relay 部署在 AWS NLB 后面，通过固定 IP 暴露
额外价值：可以替代 Subnet Router，实现全 mesh 部署 + SSH + MagicDNS

4.3 可观测性增强

tailscale ping 集成：直接看到是否走 relay、延迟多少
Prometheus 指标暴露：

- tailscaled_peer_relay_forwarded_packets_total

- tailscaled_peer_relay_forwarded_bytes_total

可直接接入 Grafana 监控

五、适用场景

5.1 受限云网络（最大卖点）

AWS VPC、GCP 的严格安全组经常阻止 P2P 打洞。过去的方案是 Subnet Router（L3 代理，单点瓶颈）。现在用 Peer Relay + 静态端点，可以实现真正的全 mesh。

5.2 跨国 / 高延迟网络

官方有个案例：一个用户从海外连 homelab，DERP 中继绕了半个地球。部署一个 Peer Relay 在中间位置后，延迟大幅下降。

5.3 数据合规

某些行业要求数据不经过第三方基础设施。Peer Relay 让流量完全留在自己的网络中。

5.4 大文件传输 / 高带宽场景

DERP 的 TCP 中继有带宽上限。Peer Relay 的 UDP 方案在传大文件、视频流等场景下表现更好。

六、对我们的实际意义

当前架构

ub2 (100.97.95.88) 通过 Tailscale 接入
ub2 需要翻墙才能访问外网（sing-box / clash 代理）
主要用途：GPU 计算、Babel 播客转录

Peer Relay 能帮到什么？

场景 1：连接质量改善

如果 ub2 和主服务器之间的直连（P2P hole-punching）有时失败，流量会回退到 DERP。DERP 节点可能在东京或新加坡，加了一跳延迟。在一个网络条件好的 VPS（比如我们的 142.93.89.244）上开 Peer Relay，可以让中继路径更短。

场景 2：ub2 在严格 NAT 后

如果 ub2 所在网络的 NAT 特别严格（Symmetric NAT），P2P 经常打不通，Peer Relay 是比 DERP 更快的 fallback。

场景 3：监控

Prometheus 指标可以帮我们了解 Tailscale 网络的实际流量模式。

实际建议

当前不急需部署。原因：

1. 我们节点少（2-3 台），P2P 直连大概率是通的

2. tailscale status 或 tailscale ping ub2 可以确认当前连接方式

3. 只有在发现频繁走 DERP 时才值得折腾 Peer Relay

如果要部署，最佳候选节点是 142.93.89.244（DigitalOcean SFO2），因为：

有公网 IP，NAT 不是问题
7×24 在线
可以同时服务所有 tailnet 节点


# 检查当前连接方式
tailscale ping ub2
tailscale status

# 如果确认需要，在 VPS 上启用 Peer Relay
tailscale set --relay-server=true

七、总结

Tailscale Peer Relays GA 是一个扎实的基础设施升级，核心价值：

1. 性能：UDP 中继，接近直连速度，比 DERP 的 TCP 方案快得多

2. 控制：流量走自己的节点，不经过 Tailscale 公共基础设施

3. 灵活：静态端点支持让云环境部署成为可能，甚至能替代 Subnet Router

4. 可观测：原生 Prometheus 指标 + ping 集成

对小规模用户（如我们）：不是刚需，但当 P2P 打洞失败频繁时，是比自建 DERP 更好的方案——配置更简单，性能更高。

对企业用户：这是个 game changer，解决了"Tailscale 在严格云网络中性能差"的老问题。

所有计划可用，包括免费的 Personal 计划。