930 字
5 分钟

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#

FeaturePeer RelayPublic DERPSelf-hosted DERP
ProtocolWireGuard (UDP)HTTPS + WebSocketHTTPS + WebSocket
LatencyLow (depends on relay location)High (shared infrastructure)Low (self-controlled)
BandwidthDepends on relay nodeLimited (QoS throttled)Depends on server
Setup difficultyLow (one command)None neededMedium (service deployment)
EncryptionWireGuard E2EWireGuard E2EWireGuard E2E
ScopeSame Tailnet onlyGlobal publicRequires extra config
Public IP neededNo (but recommended)NoYes
TIP

Peer 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
  1. Direct: Both devices establish a WireGuard tunnel via NAT traversal — lowest latency, highest speed
  2. Peer Relay: When direct connection fails, traffic is relayed through your designated Tailnet node — stays within your network
  3. DERP: When both above methods fail, falls back to Tailscale’s public DERP servers
NOTE

Peer 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:

RequirementDetails
Tailscale versionBoth client and relay node need 1.86+
Operating systemRelay nodes support Linux, macOS, Windows, etc. (not iOS, Android, Apple TV)
Account permissionsOwner, Admin, or Network admin access required for ACL configuration
QuotaFree and paid plans both allow 2 Peer Relay nodes
WARNING

Nodes 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:

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

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

TIP

If 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:

Terminal window
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:

ACL Policy
{
"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 tagged tag:office)
  • dst: Nodes authorized as relays (e.g., nodes tagged tag:relay)
  • tailscale.com/cap/relay: The capability that grants relay access
IMPORTANT

Keep the src scope 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):

Self-relay configuration
{
"grants": [
{
"src": ["my-server"],
"dst": ["my-server"],
"app": {
"tailscale.com/cap/relay": []
}
}
]
}

Region-based relay assignment:

Regional relay configuration
{
"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:

Terminal window
tailscale status | grep peer-relay

If 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:40000

Connections 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:

Terminal window
tailscale set --relay-server-port=40000 \
--relay-server-static-endpoints="203.0.113.10:40000"

Multiple addresses (IPv4 + IPv6) are supported:

Terminal window
tailscale set --relay-server-port=40000 \
--relay-server-static-endpoints="[2001:db8::1]:40000,203.0.113.10:40000"
NOTE

Static 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:

MetricDescription
forwarded_packets_totalTotal packets relayed
forwarded_bytes_totalTotal bytes relayed
relay_latencyRelay connection latency

ACL Rule Recommendations#

  • Group devices and relay nodes by geographic region (see the regional configuration example above)
  • Keep src scope 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:

UFW
sudo ufw allow 40000/udp
iptables
sudo iptables -A INPUT -p udp --dport 40000 -j ACCEPT
firewalld
sudo firewall-cmd --permanent --add-port=40000/udp
sudo firewall-cmd --reload
WARNING

Only 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/10 for 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 Setup Guide: Ditch the DERP Latency
https://catcat.blog/en/2026/03/tailscale-peer-relay-setup
作者
猫猫博客
发布于
2026-03-16
许可协议
CC BY-NC-SA 4.0