Tailscale 新功能封神！告别官方 DERP 延迟烦恼
Tailscale 的连接体验一直以「无感」著称——设备自动直连，数据走最短路径，用户几乎不需要关心底层网络在干什么。但真实世界的网络远没有这么配合。
嗨，伙伴们，用 Tailscale 组建异地互联网络的方式都体验过了吗？更多内容可以参考Tailscale：让设备互联像加好友一样简单
在网络环境相对简单的情况下，只要 Tailscale 能顺利完成打洞，实现设备之间的点对点直连，其体验往往远胜于传统 VPN 方案——更低的延迟、更高的带宽，几乎就是局域网级别的顺滑。
不过，既然说到如果，那就意味着这只是理想状态。在上一篇文章中，我们也提到过 Tailscale 的一些局限性：在不少实际场景中，网络条件并不会如此友好。比如，当我们在户外使用 5G 网络时，与家中设备的连接往往难以建立直连，大多数情况下都会退化为中继模式，随之而来的就是明显的速度下降和延迟上升。
那么问题来了，这种体验断崖式下滑的根本原因，其实在于：
-
• 运营商用超大 NAT（CGNAT）
-
• 属于对称 NAT（最严格的一种）
-
• 外部设备无法主动访问到手机
有解决办法吗？之前没有，现在有了，它就是 Peer Relays（对等中继），想了解更多内容请参考官网博客：
https://tailscale.com/blog/peer-relays-ga
Tailscale 再进化
Tailscale 的网络状态通过 tailscale status 命令进行查询：
root@vpn:~# tailscale status
100.101.22.124 vpn k2t3vskm6y@ linux -
100.68.94.8 calab k2t3vskm6y@ linux idle, tx 22599884 rx 27097496
100.122.144.128 iphone k2t3vskm6y@ iOS active; relay "tok", tx 38910136 rx 1243024
100.100.8.90 m2 k2t3vskm6y@ macOS offline, last seen 10d ago
100.83.109.4 m4 k2t3vskm6y@ macOS active; direct 222.78.1.96:64892, tx 2435083844 rx 27753681856重点关注以下内容：
-
• direct 222.78.1.96:64892
-
• relay "tok"
direct 是我们最期望看到的点到点（P2P）直连模式，后面是对应的公网 IP 和端口。
relay 代表连接类型为中继，"tok" 是 Tokyo（东京）的缩写，代表当前使用的是 Tailscale 位于日本东京的 DERP 中继节点，当两台设备之间无法通过 NAT 穿透建立 P2P 直连时，Tailscale 会自动 fallback 到最近的 DERP 服务器做中转，保证连接可用。
常见 DERP 节点缩写：
-
• tok：Tokyo（东京）
-
• sin：Singapore（新加坡）
-
• hkg：Hong Kong（香港）
-
• sfo：San Francisco（旧金山）
-
• nyc：New York City（纽约）
-
• fra：Frankfurt（法兰克福）
在 Tailscale 中，DERP 是 “Detour Encrypted Routing Protocol”（迂回加密路由协议） 的缩写，本质是 Tailscale 官方提供的加密中继服务器集群。
由上面的两张测试图也能看出来直连状态与中继状态的延迟差距有多大，中继状态时会全程绕道 Tailscale 官方的 DERP 中继服务器，延迟四百多毫秒，吞吐量也受限于公共基础设施的 QoS 策略。
这个问题在以下几种情况下几乎无法避免：运营商级 NAT（CGNAT）、严格的防火墙策略、云服务商的网络隔离、以及两端同时处于"硬 NAT"后面的情况。
对等中继（Peer Relay） 就是 Tailscale 针对这个问题给出的新答案，并于 2026 年 2 月 18 日正式宣布 GA（全面可用）。
Tailscale 的三种连接方式
在理解对等中继之前，先把 Tailscale 建立连接的完整优先级顺序捋清楚：
直连（Direct）
↓ 失败时
对等中继（Peer Relay） ← 新加入
↓ 失败时
DERP 官方中继直连是最理想的状态：两台设备通过 NAT 穿透直接建立 WireGuard UDP 隧道，延迟最低、吞吐量最高。
DERP 是终极保底方案：运行在 HTTPS 443 端口上，几乎无法被封锁，但走的是 Tailscale 的公共多租户基础设施，延迟和带宽都不在我们的控制范围内。
对等中继夹在两者之间：在我们的 tailnet 内部指定一台网络条件好的设备充当专属中继，直连失败时优先走它，而不是绕到 Tailscale 的官方节点。
三种方式都是端对端 WireGuard 加密，安全性没有区别，差的只是性能。需要特别说明的一点是，Peer Relay 服务器也是需要有公网 IP 的，家庭宽带提供的动态公网 IP 就能满足要求，不需要 DDNS（更多内容可参考告别内网穿透！家庭宽带动态公网 IP + DDNS，安全访问家中设备！）
对等中继解决了什么问题
性能更好
官方 DERP 是多租户的，带宽有 QoS 限制，服务器在海外时延迟更高。对等中继跑在我们自己的机器上，没有争抢带宽的问题，也不受任何 QoS 策略约束。
早期测试中，有用户报告对等中继的吞吐量比 DERP 高出数个数量级——对于大文件传输、视频流、数据库同步等带宽密集型场景，这个差距非常显著。
延迟更低
如果我们有一台 VPS 或者家庭服务器的地理位置恰好处于两台目标设备之间，用它做中继比绕去最近的 DERP 节点要快得多。
数据留在自己手里
流量全程在我们自己的 Tailnet 内部走，不经过第三方基础设施，对数据主权有要求的场景（企业内网、私有云）会格外在意这一点。
可以替代子网路由器
在某些部署场景里，对等中继可以取代原来的 Subnet Router 方案，实现全网格（Full Mesh）连接，同时保留 Tailscale SSH 和 MagicDNS 等核心功能。
配置步骤
整个流程非常简单，三步走：
第一步：在中继设备上开启监听
在你想用作中继的机器上执行：
tailscale set --peer-relay-udp-port=23340端口可以自定义，确保防火墙放行该 UDP 端口。如果是云服务器，建议同时配置静态端点：
tailscale set \
--peer-relay-udp-port=23340 \
--relay-server-static-endpoints="你的公网IP:23340"第二步：在 ACL 策略中授权
在 Tailscale 管理后台的 Access Controls 里，先声明标签所有者，然后用 Grant 规则把 tailscale.com/cap/relay 这个 capability 授予中继节点：
"grants": [
// Allow all connections.
// Comment this section out if you want to define specific restrictions.
{
"src": ["*"],
"dst": ["*"],
"ip": ["*"],
},
// Peer Relay
{
"src": ["*"],
"dst": ["tag:relay"],
"app": {
"tailscale.com/cap/relay": [],
},
},然后给中继设备打上 tag:relay 标签（在管理后台 Machines 页面操作）。
第三步：验证效果
tailscale ping <目标设备名或 IP>看到 via peer-relay 就说明配置生效了，测试网络延迟，远低于之前了几百毫秒。
可以看到在使用私有中继时，有时候是真实的内网地址，有时候是 Tailnet 虚拟的内网地址，无论哪一种只要出现了 via peer-relay 都代表流量未经过官方的 DERP。
哪些人最值得用
-
• 家庭服务器藏在运营商 CGNAT 后面，每次 DERP 延迟高达几百毫秒的，用一台云主机做中继可以显著改善体验。
-
• 大文件同步、Plex/Jellyfin 流媒体、数据库备份——任何在乎传输速度的场景。
-
• 经常用手机 4G/5G 访问家里 NAS、软路由的人（手机流量多是 CGNAT，P2P 直连成功率低）。
-
• 家里/办公室有动态/静态公网 IP 的人（联通、电信、移动宽带都支持，联通 NAT 策略更友好）。
-
• 跨地域/跨运营商组网（比如家里联通、办公室移动），官方 DERP 延迟高的人。
-
• 企业用户/对数据隐私敏感的人（需要完全掌控流量中转路径，满足合规要求）。
费用说明
每个 Tailnet 可以免费使用两个对等中继节点，对于个人用户和小型 Homelab 来说完全够用。超出后的收费策略目前尚未公布最终方案，Tailscale 官方表示会在后续更新中明确。
常见问题
Q1：动态公网 IP 可以用吗？需要 DDNS 吗？
可以！完全不需要 DDNS。Tailscale 会自动识别你公网 IP 的变化，无需手动更新，联通/电信/移动的动态公网都支持，亲测稳定。
Q2：部署过程中会断连现有 Tailscale 连接吗？
不会！所有操作都是“平滑变更”，不会重启网络、不会断开办公室/家里的现有连接，放心在办公室远程操作。
Q3：为什么有时候显示「peer-relay 内网IP」，有时候显示「via peer-relay(虚拟IP)」？
都是正常的！两种显示都说明走的是你自己的对等中继：
-
• 「via peer-relay 192.168.xx.xx」：手机和中继服务器 P2P 打洞成功，直连+私有中继，速度最快；
-
• 「via peer-relay(10.xx.xx.xx)」：打洞失败，走私有中继中转，依然比官方 DERP 快很多。
Q4：没有公网 IP 能部署吗？
不能。对等中继需要你的中继设备（群晖/软路由/虚拟机）能被公网访问，没有公网 IP 的话，无法实现中转，建议先联系运营商申请公网 IP（联通/电信通常免费申请）。
Q5：Tailscale 支持 IPv6 吗？和对等中继兼容吗？
支持！Tailscale 早已全面兼容 IPv6，且和对等中继功能完美适配，是没有 IPv4 公网 IP 用户的绝佳替代方案。目前国内大部分宽带（联通、电信、移动）都已支持 IPv4 + IPv6 双协议，即便没有 IPv4 公网，只要设备能获取公网 IPv6 地址，就能正常使用 Tailscale 及对等中继功能。关于公网 IPv6 的更多内容请参考家庭网络升级秘籍：如何通过 IPv6 访问家里的设备？
写在最后
Tailscale 对等中继（Peer Relays）不是“花里胡哨”的新功能，该需求在 Tailscale 社区里由来已久，很多人过去靠维护一个私有 DERP 服务器来解决这个问题，配置繁琐、维护成本高。
它是真正解决「跨网访问延迟高、速度慢」的刚需工具 —— 自 2025 年 10 月开启公开测试，2026 年 2 月正式发布，经过 5 个月的打磨，已经是稳定可用的成熟功能。
如果你经常用手机远程访问家里的设备，家里有公网 IP，那一定要部署！3 分钟搞定，部署后你会发现，远程访问家里的 NAS、软路由，和在同一个局域网里一样流畅。
💬 欢迎在留言区讨论、交流、分享~