Tailscale Peer Relay Setup Guide: Ditch the DERP Latency
Long-awaited, Tailscale’s Peer Relay is finally generally available
If you’ve used Tailscale, you’ve probably run into this: two devices are both online, yet the actual transfer speed is painfully slow with high latency. A quick tailscale status reveals the connection type as relay — traffic is being routed through Tailscale’s public DERP relay servers.
This is especially common when both sides are behind NAT. When WireGuard’s NAT traversal fails, Tailscale falls back to DERP relays. Since public DERP servers have limited bandwidth and unpredictable latency, the experience suffers.
While self-hosting DERP was always an option, it required setting up and maintaining a separate service, configuring rules, and worrying about unauthorized usage.
Now Tailscale has introduced Peer Relay, which lets you designate a node within your Tailnet as a private relay, bypassing the performance bottleneck of public DERP.
What is Peer Relay?
Peer Relay was introduced in Tailscale 1.86. It allows you to configure a node in your Tailnet as a relay server. When two devices can’t establish a direct connection, traffic is forwarded through this private relay node instead of going through public DERP.
In short, it shares the same goal as self-hosted DERP — solving performance issues when direct connections fail — but with simpler configuration and native integration.
Peer Relay vs DERP Comparison
| Feature | Peer Relay | Public DERP | Self-hosted DERP |
|---|---|---|---|
| Protocol | WireGuard (UDP) | HTTPS + WebSocket | HTTPS + WebSocket |
| Latency | Low (depends on relay location) | High (shared infrastructure) | Low (self-controlled) |
| Bandwidth | Depends on relay node | Limited (QoS throttled) | Depends on server |
| Setup difficulty | Low (one command) | None needed | Medium (service deployment) |
| Encryption | WireGuard E2E | WireGuard E2E | WireGuard E2E |
| Scope | Same Tailnet only | Global public | Requires extra config |
| Public IP needed | No (but recommended) | No | Yes |
TIPPeer Relay uses native WireGuard UDP rather than DERP’s HTTPS/WebSocket encapsulation. This is one of the key reasons for its better performance.
Connection Priority
Tailscale attempts connections in the following order:
Direct → Peer Relay → DERP- Direct: Both devices establish a WireGuard tunnel via NAT traversal — lowest latency, highest speed
- Peer Relay: When direct connection fails, traffic is relayed through your designated Tailnet node — stays within your network
- DERP: When both above methods fail, falls back to Tailscale’s public DERP servers
NOTEPeer Relay does not replace DERP. DERP is still used for connection negotiation and as the ultimate fallback. Peer Relay is an optimization layer between a failed direct connection and the DERP fallback.
Prerequisites
Before you begin, verify the following:
| Requirement | Details |
|---|---|
| Tailscale version | Both client and relay node need 1.86+ |
| Operating system | Relay nodes support Linux, macOS, Windows, etc. (not iOS, Android, Apple TV) |
| Account permissions | Owner, Admin, or Network admin access required for ACL configuration |
| Quota | Free and paid plans both allow 2 Peer Relay nodes |
WARNINGNodes used as Peer Relays should be network-stable devices with sufficient bandwidth, such as a VPS or a dedicated home server. Laptops and mobile devices are not recommended.
Configuration Steps
Step 1: Enable Relay on the Node
SSH into the node you want to use as a relay and run:
tailscale set --relay-server-port=40000This starts the Peer Relay service on UDP port 40000. You can choose a different port — just make sure the firewall allows inbound UDP traffic on it.
TIPIf your relay node is on a cloud provider (e.g., AWS, GCP), remember to allow the UDP port in your security group / firewall rules.
To disable the relay, set the port to empty:
tailscale set --relay-server-port=""Step 2: Configure ACL Grants
After enabling the relay port, you need to authorize which nodes can use this relay in Tailscale’s ACL policy.
Open the Tailscale Admin Console and add a grants rule to your ACL file:
{ "grants": [ { "src": ["tag:office"], "dst": ["tag:relay"], "app": { "tailscale.com/cap/relay": [] } } ]}Parameter explanation:
src: Devices allowed to use the relay (e.g., all devices taggedtag:office)dst: Nodes authorized as relays (e.g., nodes taggedtag:relay)tailscale.com/cap/relay: The capability that grants relay access
IMPORTANTKeep the
srcscope as narrow as possible. Avoid using the wildcard*— explicitly specify the device tags or nodes that need relay access.
Other common configurations:
Allow a node to relay for itself (useful when the node also needs to be relayed):
{ "grants": [ { "src": ["my-server"], "dst": ["my-server"], "app": { "tailscale.com/cap/relay": [] } } ]}Region-based relay assignment:
{ "grants": [ { "src": ["tag:asia-devices"], "dst": ["tag:asia-relay"], "app": { "tailscale.com/cap/relay": [] } }, { "src": ["tag:us-devices"], "dst": ["tag:us-relay"], "app": { "tailscale.com/cap/relay": [] } } ]}Step 3: Verify the Connection
After configuration, check the connection status on a client device:
tailscale status | grep peer-relayIf configured correctly, you should see the connection type change to peer-relay with the relay node’s address and port:
peer-relay 100.x.x.x:40000Connections that previously showed relay should now display peer-relay, with noticeably improved latency and speed.
Advanced Configuration
Static Endpoints
If the relay node is behind NAT (e.g., a cloud provider’s Managed NAT Gateway), Tailscale may not automatically discover its public address. You can manually specify static endpoints:
tailscale set --relay-server-port=40000 \ --relay-server-static-endpoints="203.0.113.10:40000"Multiple addresses (IPv4 + IPv6) are supported:
tailscale set --relay-server-port=40000 \ --relay-server-static-endpoints="[2001:db8::1]:40000,203.0.113.10:40000"NOTEStatic endpoints are useful for VPS with fixed public IPs or cloud environments using NAT Gateways. If your node is auto-discoverable by Tailscale, you don’t need this.
Prometheus Monitoring Metrics
Peer Relay nodes expose Prometheus-formatted metrics for integration with monitoring systems like Grafana:
| Metric | Description |
|---|---|
forwarded_packets_total | Total packets relayed |
forwarded_bytes_total | Total bytes relayed |
relay_latency | Relay connection latency |
ACL Rule Recommendations
- Group devices and relay nodes by geographic region (see the regional configuration example above)
- Keep
srcscope precise — only authorize devices that need relaying - Periodically review ACL rules and remove outdated authorizations
Firewall Configuration
Make sure the relay node’s firewall allows the designated UDP port:
sudo ufw allow 40000/udpsudo iptables -A INPUT -p udp --dport 40000 -j ACCEPTsudo firewall-cmd --permanent --add-port=40000/udpsudo firewall-cmd --reloadWARNINGOnly UDP needs to be allowed — Peer Relay doesn’t use TCP. It’s also recommended to restrict the source IP to Tailscale’s CGNAT range
100.64.0.0/10for added security.
Summary
Peer Relay addresses Tailscale’s performance pain point in restrictive NAT environments. Compared to self-hosted DERP, it’s simpler to configure and uses native WireGuard protocol for better performance.
Related links:
- Tailscale Peer Relay documentation: https://tailscale.com/kb/1532/peer-relay
- Tailscale ACL Grants documentation: https://tailscale.com/kb/1324/acl-grants