NAT Checker

Tailscale Peer Relay: Build a Faster Relay Path

Generate the right relay command and grant policy, then verify whether traffic is direct, peer-relay, or DERP.

Build my relay plan

Direct

Fastest when possible

Peer relay

Better throughput when direct fails

DERP

Reliable managed fallback

Quick answer

Tailscale tries a direct connection first, a configured peer relay second, and DERP last. A peer relay can improve throughput when strict NAT, CGNAT, or firewalls block a direct path.

Build your Tailscale peer relay plan

Select the relay host, its internet edge, and your goal. The planner generates the matching listener, firewall, access policy, and validation sequence; replace the example tags and addresses before use.

1. Relay host
2. Internet edge
3. Main goal

Placement advice

Place the relay on a wired, always-on device with fast paths to both peers. Benchmark the same endpoints before and after.

Relay command
tailscale set --relay-server-port=40000
Linux firewall
sudo ufw allow 40000/udp
Least-privilege grant policy
{
  "grants": [
    {
      "src": ["tag:client"],
      "dst": ["tag:peer-relay"],
      "app": { "tailscale.com/cap/relay": [] }
    }
  ]
}
Verify the connection path
tailscale ping <peer-name-or-ip>
tailscale status

How a Tailscale peer relay fits the route

Tailscale first tries to build a direct encrypted connection. When NAT traversal fails, an authorized peer relay gives the tailnet a route you control before traffic falls back to a Tailscale DERP relay. That makes peer relay useful for hard NAT, predictable regional routing, and large transfers—not for replacing a healthy direct connection.

01

Direct

Best path when both peers can traverse NAT.

02

Peer relay

Your authorized, reachable tailnet device.

03

DERP

Reliable managed fallback when needed.

Peer relay vs direct connection vs DERP

These are connection paths, not three VPN products. Tailscale chooses them in order, so a working direct connection normally remains the target while peer relay and DERP provide resilience.

PathSelection orderBest useTrade-off
DirectFirstNormal peer-to-peer trafficMay fail across hard NAT or restrictive firewalls
Peer relayAfter direct failsA controlled, potentially higher-throughput fallbackYou operate the reachable relay host and UDP path
DERP relayLast fallbackReliable connectivity without your own relay hostLonger route or lower throughput in some locations

Prerequisites before setup

A relay command cannot fix an unreachable listener. Confirm the software, permissions, tags, and entire UDP route before troubleshooting throughput.

  • Tailscale 1.86 or later on the relay host and clients
  • An always-on relay device that is not iOS, Android, or Apple TV
  • Tailnet owner, admin, or network-admin access to edit policy
  • A stable, reachable UDP port such as 40000
  • Tags that distinguish clients from the peer relay

Four-step setup

Use the generated plan above, then validate every layer in this order.

  1. 1

    Enable the listener

    Run the relay command on the chosen host and confirm the Tailscale service remains healthy.

  2. 2

    Apply the relay grant

    Replace the example tags with your own least-privilege source and destination groups.

  3. 3

    Open the UDP path

    Match UDP 40000 across the host firewall, router or load balancer, and any cloud firewall.

  4. 4

    Force a realistic test

    Test from networks where direct connectivity fails, then inspect ping and status before measuring speed.

Test the real path, not just reachability

A successful ping proves the peer is reachable. Its path label tells you whether the traffic is direct, peer-relay, or DERP; a controlled endpoint-to-endpoint benchmark tells you whether the relay is faster.

Path and throughput checks
tailscale ping <peer-name-or-ip>
tailscale status
iperf3 -c <peer-tailscale-ip> -P 4

direct

NAT traversal worked. Do not force a relay unless you have a measured reason.

peer-relay

The configured relay is active. Compare throughput and latency with the prior path.

DERP

The peer relay was not selected. Check grant, UDP reachability, and endpoint advertising.

Why Tailscale still uses DERP

Work from control plane to data plane. A relay can be online in the admin console while its UDP listener is unreachable from the client network.

Fast diagnosis order

Version → tags → relay grant → listener → host firewall → router or cloud edge → client network UDP.

Measure peer relay speed fairly

Keep the endpoints constant

Use the same client, server, file or iperf3 stream count, and time window. Record path labels with every result.

Watch both relay legs

The slower client-to-relay or relay-to-destination leg caps the transfer. Wi-Fi and CPU can matter more than the port number.

Repeat at busy and quiet times

One short run can hide congestion and route changes. Compare medians instead of presenting one peak as a limit.

Keep DERP as the control

A peer relay is useful only when it improves the real workload or gives you needed route control and auditability.

Tailscale peer relay FAQ

Direct answers to the setup, path selection, ports, Windows, speed, DERP, and disable questions people ask most.

Check the network around your relay

Use these focused guides when the planner exposes an upstream NAT or routing dependency.

Check for CGNAT before choosing a relay hostCompare the router WAN address with the public internet address.Understand Tailscale ports and router forwardingSeparate transport ports from the application you are trying to reach.Compare a Tailscale exit node with a peer relayAn exit node changes internet egress; a peer relay changes a tailnet path.Test for double NAT before forwarding UDPA second router can make an otherwise correct port mapping unreachable.

Official references

Peer relay requirements and CLI syntax can change. Check the current primary documentation before a production rollout.

Peer relay feature documentationDirect and relayed connection typesTailscale CLI reference
Share this article