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 计划。