Tailscale Peer Relays became generally available on February 18, 2026, giving organizations a way to keep relayed traffic inside their own infrastructure. This feature enables devices within a Tailscale network (tailnet) to act as high-throughput relay servers when direct connections fail due to restrictive NATs or firewalls. Unlike Tailscale’s global DERP (Designated Encrypted Relay for Packets) servers, peer relays run on your own infrastructure, delivering significantly lower latency and higher throughput while maintaining end-to-end encryption. The feature is the work of the same team behind Tailscale’s broader infrastructure ambitions, including co-founder David Crawshaw’s solo-stack cloud project.
This article was updated June 2026 to correct version attributions in the changelog, reflect the current stable client release, and add measured throughput numbers Tailscale has since published.
What Are Tailscale Peer Relays?
Tailscale Peer Relays are customer-deployed relay servers that forward encrypted traffic between tailnet devices when direct P2P connections cannot be established. When two devices cannot connect directly due to network restrictions, Tailscale first attempts to use an available peer relay before falling back to DERP servers. (Tailscale. “Tailscale Peer Relays.” Tailscale Docs, 2026)
The concept addresses a fundamental limitation in mesh VPN architectures: while direct connections provide optimal performance, real-world networks often block them through strict NAT configurations, corporate firewalls, or cloud networking constraints. Before peer relays, Tailscale users had to rely on DERP servers (globally distributed relay infrastructure maintained by Tailscale), which could introduce additional latency, especially for high-throughput applications. (Tailscale. “Tailscale Peer Relays is now generally available.” Tailscale Blog, February 18, 2026)
Peer relays require Tailscale version 1.86 or later and are available on all Tailscale plans, including the free Personal plan. They support any operating system except iOS, Apple TV, or Android for the relay server itself, while client devices can use any supported Tailscale platform. (Tailscale. “Peer Relay Requirements.” Tailscale Docs, 2026)
How Do Peer Relays Work?
The architecture of Tailscale Peer Relays slots into Tailscale’s existing connectivity model. When a device attempts to establish a connection, Tailscale evaluates the network path according to the following priority:
- Direct connection via UDP hole punching using STUN and ICE protocols
- Peer relay connection through customer-deployed relay servers
- DERP relay connection via Tailscale’s global relay infrastructure (Tailscale. “Device Connectivity.” Tailscale Docs, 2026)
When you designate a device as a peer relay, it listens on a specified UDP port for relay traffic. Other devices in the tailnet can then forward encrypted packets through this relay when direct paths are unavailable. The relay server receives already-encrypted WireGuard packets and forwards them to the destination. Because private keys never leave the local device, the relay cannot decrypt traffic. (Tailscale. “DERP Servers.” Tailscale Docs, 2026)
Configuration Requirements
Setting up a peer relay involves two steps. First, configure the relay device using the Tailscale CLI:
tailscale set --relay-server-port=40000Optionally, specify static endpoints for environments where automatic endpoint discovery fails:
tailscale set --relay-server-static-endpoints="203.0.113.1:40000,[2001:db8::1]:40000"Second, create a grant policy in your tailnet policy file to authorize specific devices to use the relay:
{ "src": ["tag:us-east-vpc"], "dst": ["tag:peer-relay"], "app": { "tailscale.com/cap/relay": {} }}Why Do Peer Relays Matter?
Peer relays address three critical challenges in enterprise networking: performance, control, and visibility.
Performance Improvements
The performance work landed across several releases rather than in one GA drop, and the changelog dates matter if you are pinning a client version. [Updated June 2026] Support for multiple forward-bind packets per handshake generation, which improves path selection and the odds of completing a handshake, shipped in v1.92.1 (December 10, 2025). The throughput gains from monotonic time comparison optimizations and reduced lock contention shipped in v1.94.1 (January 26, 2026), along with SO_REUSEPORT multi-socket UDP handling on Linux. v1.96.2 (March 18, 2026) added automatic address discovery for relays on Amazon EC2. Connecting clients also select optimal interfaces and address families when multiple options exist within a single relay. (Tailscale. “Changelog.” Tailscale, 2026)
The gains are not hypothetical. On a Delhi-to-Minneapolis path that Tailscale measured, a single subnet router moved from 2.2 Mbit/s over DERP(ord) to 27.5 Mbit/s through a peer relay, roughly a 12x increase, while round-trip latency dropped from about 452 ms to 306 ms. (Tailscale. “Tailscale Peer Relays on international networks.” Tailscale Blog, January 26, 2026) The latency reduction is the smaller story; the throughput jump is what makes relayed paths usable for sustained transfers rather than just control traffic. For comparison, a same-region DERP hop already costs real time: Tailscale’s own connection-types reference shows a session at 130 ms via DERP(nyc) collapsing to 35 ms once a direct path is found. (Tailscale. “Connection Types.” Tailscale Docs, 2026) A peer relay sits between those two regimes: slower than direct, but materially faster and higher-throughput than a shared public relay because you size the bandwidth and place the node close to your devices.
Cloud and Restrictive Environment Support
Many cloud environments present challenges for traditional NAT traversal. Instances may sit behind strict firewall rules, rely on port forwarding, or operate behind load balancers that prevent automatic endpoint discovery. Peer relays now support static endpoints specifically for these scenarios. (Tailscale. “Static Endpoints for Peer Relays.” Tailscale Blog, February 18, 2026)
Using the --relay-server-static-endpoints flag, a peer relay can advertise fixed IP:port pairs that work behind infrastructure like AWS Network Load Balancers. The flag itself arrived in v1.92.1 (December 10, 2025). v1.96.2 then reduced the manual configuration burden for EC2 deployments specifically: peer relays running on EC2 instances now automatically discover and advertise their network addresses via the Amazon EC2 Instance Metadata Service, so static endpoints are no longer required in most AWS configurations. [Updated June 2026]
Enhanced Observability
The GA release integrates peer relays deeply into Tailscale’s visibility tooling. Administrators can use tailscale ping to verify relay connectivity and measure latency impact; the ping view became peer-relay-aware in v1.92.1, so a relayed hop now prints its path explicitly, for example via peer-relay(67.4.225.236:7777:vni:619) in 306ms. Peer relays also expose Prometheus-compatible metrics including tailscaled_peer_relay_forwarded_packets_total and tailscaled_peer_relay_forwarded_bytes_total, enabling teams to monitor relay usage, detect anomalies, and understand traffic patterns across a fleet. A third gauge metric, tailscaled_peer_relay_endpoints, added in v1.94.1, reports the number of tunnels currently served by the local relay instance with a state label distinguishing connecting from open endpoints. [Updated June 2026] (Tailscale. “Client Metrics.” Tailscale Docs, 2026)
Connection Types: A Comparison
Tailscale devices can establish three types of connections depending on network conditions. The following table compares their characteristics:
| Connection Type | When Used | Performance | Infrastructure |
|---|---|---|---|
| Direct | Both devices have public IPs or easy NAT | Optimal, no intermediary | None required |
| Peer Relay | One or both devices behind hard NAT | High, customer-controlled infrastructure | Customer-deployed relay |
| DERP Relay | Direct and peer relay unavailable | Good, may have higher latency | Tailscale-managed global servers |
The NAT configuration of each device determines the connection type. When both devices operate behind “hard NAT” configurations (restrictive NATs that use complex port allocation strategies and disable port mapping protocols), Tailscale cannot establish direct connections and must use relayed connections. (Wikipedia contributors. “NAT Traversal.” Wikipedia, The Free Encyclopedia)
NAT Traversal: The Technical Foundation
Understanding peer relays requires understanding NAT traversal. Network Address Translation (NAT) maps private IP addresses to public IPs, enabling multiple devices to share internet connectivity. However, NAT creates challenges for P2P networking because devices behind NATs cannot easily receive unsolicited inbound connections. (Tailscale. “How NAT Traversal Works.” Tailscale Blog)
Tailscale employs several IETF-standard techniques to traverse NATs:
- STUN (Session Traversal Utilities for NAT): RFC 5389 defines this protocol for discovering the public IP and port allocated by a NAT device (Rosenberg, J., et al. “RFC 5389: Session Traversal Utilities for NAT (STUN).” IETF, October 2008)
- ICE (Interactive Connectivity Establishment): RFC 8445 describes this framework for establishing connectivity between peers across NATs (Keranen, A., et al. “RFC 8445: Interactive Connectivity Establishment (ICE).” IETF, July 2018)
- TURN (Traversal Using Relays around NAT): RFC 5766 specifies relay-based traversal when direct connections fail (Reddy, A., et al. “RFC 5766: Traversal Using Relays around NAT (TURN).” IETF, April 2010)
When STUN and ICE succeed, devices establish direct WireGuard tunnels. When they fail (such as in symmetric NAT scenarios or when UDP is blocked), Tailscale falls back to relayed connections via peer relays or DERP servers.
Enterprise Use Cases
Peer Relays open up several enterprise scenarios that were previously awkward with mesh VPNs:
- Multi-cloud connectivity: Deploy peer relays in each cloud region to ensure low-latency paths between VPCs when direct connections fail
- Strict compliance environments: Maintain complete control over relay infrastructure while still benefiting from Tailscale’s mesh architecture
- High-throughput workloads: Support video production, scientific computing, or data pipeline workloads that require sustained bandwidth
- Legacy network integration: Replace subnet routers with full-mesh deployments that support Tailscale SSH and MagicDNS (Tailscale. “Subnet Routers vs Peer Relays.” Tailscale Docs, 2026)
Why a Relay Cannot Read Your Traffic
The security claim rests entirely on WireGuard’s design, not on a policy promise from Tailscale. WireGuard is built on the Noise protocol framework and uses a fixed set of primitives: Curve25519 for key agreement, ChaCha20-Poly1305 for authenticated encryption, and BLAKE2s for hashing. (WireGuard. “Protocol & Cryptography.” WireGuard, 2026) Each pair of peers derives session keys from their own private keys, which never leave the device. A peer relay sits in the data path but holds none of those keys, so it forwards ciphertext it cannot open. The relay sees source and destination endpoints and packet sizes; it does not see plaintext. This is the same property that lets an untrusted forwarder be useful at all, and it is structurally identical to designs like Secluso, an open-source camera that routes encrypted footage through a relay server it cannot read.
One consequence worth stating plainly: WireGuard itself does no NAT traversal, no discovery, and no relaying. The protocol is connectionless UDP and assumes something else tells it which endpoint to send to. Everything in this article, hole punching, DERP, peer relays, is Tailscale’s coordination layer wrapped around an otherwise inert transport. That separation is why Tailscale can change its relay strategy without touching the cryptographic core, and why a relay swap does not weaken the end-to-end guarantee.
A peer relay is also closer to a TURN server (RFC 5766) than to DERP in spirit, but it differs in a way that matters operationally. DERP multiplexes traffic by destination public key across always-on shared infrastructure, so any tailnet device can use it without prior arrangement. A peer relay forwards only between devices that a grant in your policy file explicitly authorizes through the tailscale.com/cap/relay capability. The relay is dedicated to your tailnet, runs on hardware you chose, and stays inert until a grant points traffic at it.
How Peer Relays Compare to Other Mesh VPNs
Every mesh VPN has to solve the same problem: two peers behind hostile NATs need a forwarder when hole punching fails. The designs diverge on who runs that forwarder and whether discovery and relaying are the same component.
| System | Discovery | Relay / fallback | Vendor safety net | Layer |
|---|---|---|---|---|
| Tailscale | Control plane + STUN/ICE | Peer relay (any tailnet node) or DERP | Yes, global DERP fleet | L3 (IP over WireGuard) |
| NetBird | Dedicated Signal server | Dedicated Relay tier (QUIC, WS/TCP fallback) | Hosted relay available | L3 (WireGuard) |
| Nebula | Lighthouses (static-IP nodes) | Relay hosts (separate config) | No hosted relay; self-run | L3 (Noise, not WireGuard) |
| ZeroTier | Roots (the “planet”) | Roots, or user “moons” | Yes, ZeroTier roots | L2 (virtual Ethernet) |
NetBird, which raised a $10M Series A in January 2026 and positions itself as a European open-source alternative, keeps discovery and relaying as two distinct services: a Signal server brokers ICE candidates then steps aside, and a separate Relay tier forwards data. NetBird replaced its earlier Coturn/TURN relay with a custom QUIC relay (with WebSocket/TCP fallback when UDP is blocked) starting in v0.29.0. (NetBird. “How NetBird Works.” NetBird Docs, 2026) The contrast with Tailscale is structural: NetBird runs a dedicated relay role, while a Tailscale peer relay is just an ordinary node you flagged.
Nebula, the mesh originally built at Slack and now maintained by Defined Networking, draws the cleanest line between discovery and forwarding. Lighthouses are static-IP nodes that act purely as a registry for hole punching; relay hosts are a separate, statically configured role that forwards traffic when a direct path fails. (Defined Networking. “Announcing Relay Support in Nebula.” Defined Networking Blog, 2026) Nebula uses the Noise framework directly rather than WireGuard, and it ships no hosted fallback at all. If your direct path and your relay host both fail, the connection fails. There is no DERP-equivalent to catch it, which is either a liability or a feature depending on how much you distrust vendor infrastructure.
ZeroTier is the outlier on two axes. It operates at Layer 2, presenting a virtual Ethernet segment rather than Tailscale’s Layer 3 IP fabric, and it fuses discovery and relaying into a single role. Root servers (collectively the “planet”) perform STUN-like hole punching and relay as fallback; user-defined “moons” are supplementary roots that can also relay. The closest ZeroTier analog to a peer relay is the private moon, and as of 2026 ZeroTier’s own documentation marks private moons as deprecated and outside its support SLA, which leaves self-hosted relaying on ZeroTier in an awkward spot. (ZeroTier. “Roots.” ZeroTier Docs, 2026)
For anyone running Headscale, the open-source Tailscale control-server, peer-relay support landed in v0.29.0 (June 2026) via the same grants-and-via policy machinery Tailscale uses. It is not quite at parity: a known issue requires authorized nodes to reach the relay node directly, where Tailscale’s hosted control plane does not. (juanfont. “Track for supporting Tailscale Peer Relays.” Headscale GitHub, 2026) Self-hosters should treat it as new rather than settled.
One currency note for anyone pinning versions: the latest stable Tailscale client as of June 2026 is v1.98.5, and none of the v1.96.3 through v1.98.5 releases changed peer-relay behavior. [Updated June 2026] The feature set described here is the one that shipped through v1.96.2; later releases focused on Apple toolchain updates, MagicDNS, and preset app definitions rather than relaying.
Frequently Asked Questions
Q: What is the difference between a peer relay and a DERP server? A: Peer relays are customer-deployed devices within your tailnet that relay encrypted traffic when direct connections fail. DERP servers are Tailscale-managed global relays that serve as the final fallback. Peer relays typically offer better performance because they run on your infrastructure closer to your devices.
Q: Can peer relays decrypt my traffic? A: No. Peer relays forward already-encrypted WireGuard packets. Because Tailscale private keys never leave the local device that generated them, it is impossible for any relay to decrypt traffic.
Q: When should I use peer relays instead of subnet routers? A: Peer relays can replace subnet routers when you want full-mesh connectivity with features like Tailscale SSH and MagicDNS. Subnet routers require traffic to flow through a central node, while peer relays enable direct device-to-device connections even through restrictive NATs.
Q: Are peer relays available on all Tailscale plans? A: Yes. Peer Relays are available on all Tailscale plans, including the free Personal plan, as of the February 18, 2026 GA announcement.
Q: How do I verify that traffic is using a peer relay? A: Use the tailscale status command and look for connections marked as peer-relay instead of direct or relay. You can also use tailscale ping to test connectivity and observe the connection path, which prints the relay endpoint inline, for example via peer-relay(<ip>:<port>:vni:<id>) in 306ms.
Q: How do peer relays differ from NetBird, Nebula, or ZeroTier relaying? A: NetBird and Nebula both run a dedicated relay role that is separate from discovery, and Nebula ships no hosted fallback at all. ZeroTier relays through root servers and its self-hosted “moon” relay is now deprecated. A Tailscale peer relay is distinct in that it is just an ordinary tailnet node you flagged, authorized per-grant, with the global DERP fleet still available as a final fallback.
Q: Does self-hosted Headscale support peer relays? A: Yes, as of Headscale v0.29.0 (June 2026), using the same grant policies and tailscale.com/cap/relay capability. It is not yet at full parity with Tailscale’s hosted control plane; a known issue requires authorized nodes to reach the relay node directly.
