加载失败
Tailscale 发布 Peer Relays 功能，允许用户将自己网络中的节点配置为中继，以替代或补充其托管的 DERP 中继，目标是降低延迟并提高在 NAT/防火墙受限环境中的吞吐。讨论建立在 Tailscale 基于 WireGuard 的点对点优先拓扑之上，并由 NAT 穿透失败、DERP 性能瓶颈和控制平面依赖这些现实问题驱动。评论里把该功能与老牌工具（如 tinc）、替代方案（Nebula、innernet）以及自托管控制面 Headscale 相比较，并深入讨论了端口/ACL、平台支持（iOS/浏览器）和收费疑虑等具体运维问题。总体语境是用户希望在不丢失端到端加密与控制权的前提下，获得更可靠、更高吞吐的回退中继方案。
Tailscale Peer Relays 让用户在无法建立直接 P2P 连接时指定网络内节点作为中继，从而替代 Tailscale 托管的 DERP 回退。评论指出中继仅在直连不可行时转发流量并保持端到端加密，能利用自有带宽与更合适的地理位置显著提高吞吐与延迟表现（许多人因 DERP 性能差而自建过替代方案）。相比公有 DERP，私有 peer relay 可以降低对 Tailscale 公共中继的依赖并将流量放在自己可控的机器/网络上，适用于云到本地或需要高带宽的服务整合场景。用户也期待借此替换自己过去为性能而维护的自建 DERP 实例。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
有人指出 tinc 早已支持任意节点作为中继并实现真正的去中心化 mesh，建议将其思想移植到 WireGuard 并用内存安全语言重写以免重复造轮子；但也有用户报告 tinc 在跨公网环境中会发生路由抖动、且中继节点会对流量做解密/重加密，端到端加密的实验性功能未正式发布。Nebula 被提为更现代的替代方案，支持 peer discovery、NAT hole punching 并使用 Noise Protocol；innernet 等项目也被提及但有人认为仍带有集中/联邦化特性。讨论总体把难点归结为 NAT 穿透与发现问题本身（很多场景需要至少一个公网可达节点），因此单靠 WireGuard 协议并不能自动解决这些问题，需要额外的控制平面或公开节点来协助穿透与配置。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
实践中对部署细节存在具体疑问：peer relay 使用用户选定的 UDP 端口，通常需要在公网 IP 上打开一个 UDP 端口（有评论提到 Tailscale Disco 协议在该底层端口运行），但关于是否仅接受来自 tailnet 的流量或必须完全开放到公网仍有讨论。移动与浏览器平台存在限制：iOS/tvOS 受 NetworkExtension 二进制大小限制暂时无法支持；浏览器端因不能使用原生 UDP 被认为短期内不可用，可能需要借助 WebTransport，但 WebTransport 本身并不解决 NAT 穿透问题。跨 tailnet/共享场景也带来权限与 ACL 的复杂性：文档建议将 src 设为位于受限 NAT 的稳定物理位置，且在共享关系下中继绑定可见性与授权需要小心配置。用户同时询问是否可强制使用中继（而非仅作回退），以在某些消费者网络中获得更稳定或更快的路径，这在现有实现中仍是关注点。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
评论中多次提到对控制平面依赖带来的可用性风险：当 Tailscale 的登录或控制服务器出现故障时，本地设备有时会完全断开且无法互通，有人报告过类似事件并寻求自托管替代方案。Headscale（一个开源的 Tailscale 控制面实现）被多次推荐并且有用户验证在断网情况下仍能保留局域网内设备互通，从而提升离线韧性。讨论还提到在更低层面可通过为 WireGuard 支持多个端点或配置 ULA 地址等方式缓解局域网断网场景，但这些通常需要额外配置或内核/实现层的支持。总体上，若需在无外网时保持本地可达，自托管控制面是被广泛采纳的方向。
关于定价策略与“用自有基础设施改善连接是否应收费”引发争议：官方公告默认每个用户可免费使用两个 peer relay，但超出后需与 Tailscale 联系以添加更多，中有用户质疑为何要为把自己服务器当中继而付费。Tailscale 内部有人回应倾向于不对该功能收费（主要成本为支持），但也说明早期保守发布有其理由。另有评论强调，运行自己的 peer relay 是改善自家网络性能的自托管行为，并非在无偿“捐赠”流量给 Tailscale 的公共基础设施，因此对是否收费的担忧来自沟通与定位的不明确。
DERP: Tailscale 的 Designated Encrypted Relay for Packets（DERP）是其托管的云中继集群，用作 P2P 失败时的回退路径。DERP 代理流量以维持连通性并通常保持端到端加密，但用户常抱怨其吞吐与延迟较差。Peer Relay 的出现就是为了解决 DERP 在某些场景下的性能瓶颈。
NAT 穿透（NAT hole punching）: 使位于 NAT 或防火墙后的双方直接建立 P2P 连接的技术，通常需要 STUN、协调服务器或至少一个公网可达节点来辅助建立映射。评论中多次指出失败的 P2P 往往是因为 NAT 行为而非加密协议本身，故需要辅助机制来实现可靠穿透。
Headscale: Headscale 是一个开源的自托管 Tailscale 控制面实现（在 GitHub 上），用于替代 Tailscale 的登录/控制服务器。运行 Headscale 可以让组织在不依赖 Tailscale 公有控制面的情况下管理节点并在外网断开时保持局域网内可达。
tinc: tinc 是一个历史悠久的去中心化 mesh VPN 实现，允许任意节点充当中继并形成全网状拓扑。讨论指出 tinc 在路由稳定性、某些场景下的中继行为（解密/重加密）以及端到端加密方面存在已知限制，因而有人建议将其设计思想结合 modern protocols（如 WireGuard）重写。
WireGuard: WireGuard 是一种现代、轻量级的加密隧道协议，提供高性能的加解密和简单配置。WireGuard 本身不包含节点发现或自动 NAT 穿透协调，通常需要控制平面（如 Tailscale）或额外工具来做 peer discovery 与穿透。
WebTransport: WebTransport 是基于 HTTP/3 的浏览器端双向传输 API，可实现类似 UDP 的长连接和双向流通信。评论认为它可能是浏览器端实现中继的可行方向，但 WebTransport 并不本质解决 NAT 穿透问题。