Table of Contents

Tailscale Peer Relays became generally available on February 18, 2026, marking a significant milestone for organizations seeking true peer-to-peer (P2P) networking capabilities. 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.

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.1

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.2

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.3

How Do Peer Relays Work?

The architecture of Tailscale Peer Relays integrates seamlessly with Tailscale’s existing connectivity model. When a device attempts to establish a connection, Tailscale evaluates the network path according to the following priority:

  1. Direct connection via UDP hole punching using STUN and ICE protocols
  2. Peer relay connection through customer-deployed relay servers
  3. DERP relay connection via Tailscale’s global relay infrastructure4

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.5

Configuration Requirements

Setting up a peer relay involves two steps. First, configure the relay device using the Tailscale CLI:

Terminal window
tailscale set --relay-server-port=40000

Optionally, specify static endpoints for environments where automatic endpoint discovery fails:

Terminal window
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 GA release of Peer Relays delivers substantial throughput optimizations. Connecting clients now select optimal interfaces and address families when multiple options exist within a single relay. The relay server itself benefits from reduced lock contention and multi-socket UDP handling on multi-core systems.6

For high-throughput scenarios—such as large file transfers, media streaming, or database replication—peer relays offer performance much closer to true mesh networking than DERP servers can provide. Because you control the relay infrastructure, you can provision bandwidth according to your specific requirements rather than sharing public relay capacity.

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.7

Using the --relay-server-static-endpoints flag, a peer relay can advertise fixed IP

pairs that work behind infrastructure like AWS Network Load Balancers. This enables high-throughput connectivity in environments where standard NAT traversal and endpoint discovery fail.

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. Additionally, peer relays 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 at scale.8

Connection Types: A Comparison

Tailscale devices can establish three types of connections depending on network conditions. The following table compares their characteristics:

Connection TypeWhen UsedPerformanceInfrastructure
DirectBoth devices have public IPs or easy NATOptimal—no intermediaryNone required
Peer RelayOne or both devices behind hard NATHigh—customer-controlled infrastructureCustomer-deployed relay
DERP RelayDirect and peer relay unavailableGood—may have higher latencyTailscale-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.9

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.10

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 device11
  • ICE (Interactive Connectivity Establishment): RFC 8445 describes this framework for establishing connectivity between peers across NATs12
  • TURN (Traversal Using Relays around NAT): RFC 5766 specifies relay-based traversal when direct connections fail13

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 unlock several enterprise scenarios that were previously challenging 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 MagicDNS14

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.


Footnotes

  1. Tailscale. “Tailscale Peer Relays.” Tailscale Docs, 2026. https://tailscale.com/docs/features/peer-relay

  2. Tailscale. “Tailscale Peer Relays is now generally available.” Tailscale Blog, February 18, 2026. https://tailscale.com/blog/peer-relays-ga

  3. Tailscale. “Peer Relay Requirements.” Tailscale Docs, 2026. https://tailscale.com/docs/features/peer-relay

  4. Tailscale. “Device Connectivity.” Tailscale Docs, 2026. https://tailscale.com/docs/reference/device-connectivity

  5. Tailscale. “DERP Servers.” Tailscale Docs, 2026. https://tailscale.com/docs/reference/derp-servers

  6. Tailscale. “Changelog - Tailscale v1.94.1.” Tailscale, January 26, 2026. https://tailscale.com/changelog

  7. Tailscale. “Static Endpoints for Peer Relays.” Tailscale Blog, February 18, 2026. https://tailscale.com/blog/peer-relays-ga

  8. Tailscale. “Client Metrics.” Tailscale Docs, 2026. https://tailscale.com/kb/1482/client-metrics

  9. Wikipedia contributors. “NAT Traversal.” Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/NAT_traversal

  10. Tailscale. “How NAT Traversal Works.” Tailscale Blog. https://tailscale.com/blog/how-nat-traversal-works

  11. Rosenberg, J., et al. “RFC 5389: Session Traversal Utilities for NAT (STUN).” IETF, October 2008. https://datatracker.ietf.org/doc/html/rfc5389

  12. Keranen, A., et al. “RFC 8445: Interactive Connectivity Establishment (ICE).” IETF, July 2018. https://datatracker.ietf.org/doc/html/rfc8445

  13. Reddy, A., et al. “RFC 5766: Traversal Using Relays around NAT (TURN).” IETF, April 2010. https://datatracker.ietf.org/doc/html/rfc5766

  14. Tailscale. “Subnet Routers vs Peer Relays.” Tailscale Docs, 2026. https://tailscale.com/docs/features/peer-relay

Enjoyed this article?

Stay updated with our latest insights on AI and technology.