Tailscale Peer Relays are a tailnet fallback when direct paths fail

Tailscale Peer Relays are a tailnet fallback when direct paths fail

Tailscale Peer Relays let a tailnet use an explicitly configured device as a relay when direct connectivity is unavailable. A relay can keep traffic on infrastructure the operator chooses and improve a path that would otherwise use a distant shared relay. It remains a relay connection. Tailscale tries direct connectivity first, then an available peer relay, and uses DERP if it cannot use either. (Tailscale. “Tailscale Peer Relays.” Tailscale Docs, 2026)

That order explains the useful deployment case: two devices repeatedly fail to establish a direct path, and a reachable relay in a better location can forward their encrypted traffic. A relay’s benefit depends on placement, bandwidth and the networks on both sides. It is not a throughput guarantee or a replacement for Tailscale’s DERP fallback. The Tailscale Peer Relays is now generally available announcement describes the customer-operated relay option.

Start by checking the path

A direct connection sends traffic between devices without a forwarding server. A peer relay supplies a forwarding device selected and authorized within the tailnet. DERP supplies Tailscale’s distributed relay infrastructure when the other paths are unavailable. (Tailscale. “Device Connectivity.” Tailscale Docs, 2026; Tailscale. “DERP Servers.” Tailscale Docs, 2026)

Use tailscale ping and tailscale status to observe the connection type before changing the deployment. Repeat the check after configuring the relay and under the network conditions that cause trouble. The Tailscale. “Connection Types.” Tailscale Docs, 2026 reference documents these diagnostic views. For a cloud-hosted deployment, measure latency impact across the routes the endpoints actually use.

NAT and firewall conditions explain why a direct route can fail even when both devices can reach the internet. NAT maps addresses and ports, and the two endpoints may disagree about which externally reachable path is usable. Tailscale’s Tailscale. “How NAT Traversal Works.” Tailscale Blog explains the practical negotiation and traversal problem.

For protocol background, STUN describes how a client discovers an externally mapped address and port, while ICE describes gathering and checking candidate paths. (Rosenberg, J., et al. “RFC 5389: Session Traversal Utilities for NAT (STUN).” IETF, October 2008; Keranen, A., et al. “RFC 8445: Interactive Connectivity Establishment (ICE).” IETF, July 2018) Diagnose Tailscale with its actual path reports rather than inferring a successful direct connection from the presence of a public IP address.

Configure a reachable relay and a grant

The current general guide requires Tailscale 1.86 or later on the relay and participating tailnet devices. The relay itself can run on supported operating systems other than iOS, Apple TV or Android. It needs sufficient bandwidth, useful latency and a configurable UDP port reachable by the other devices. The version requirement does not demonstrate that a particular firewall, load balancer or host is ready. (Tailscale. “Peer Relay Requirements.” Tailscale Docs, 2026)

Enable the relay’s UDP listener, using the documented example port:

tailscale set --relay-server-port=40000

For deployments that need explicitly advertised public endpoints, the CLI also supports static endpoints:

tailscale set --relay-server-static-endpoints="203.0.113.1:40000,[2001:db8::1]:40000"

Those are documentation addresses: replace them with reachable endpoints for the relay. The GA article describes the static-endpoint option. (Tailscale Peer Relays is now generally available: static endpoints)

Next, authorize the intended devices through a grant in the tailnet policy. This example allows a tagged workload group to use tagged relay devices:

{
  "grants": [
    {
      "src": ["tag:us-east-vpc"],
      "dst": ["tag:peer-relay"],
      "app": {
        "tailscale.com/cap/relay": []
      }
    }
  ]
}

The tailscale.com/cap/relay capability controls which devices can use the relay. Keep ordinary traffic authorization in the tailnet policy as well: installing a relay is not a reason to broaden which applications or devices may communicate. Check reachability and the grant independently when a relay is configured but the devices still use DERP.

A relay forwards ciphertext

Peer relays forward encrypted traffic rather than becoming an application endpoint with access to plaintext. The international-network account states that a peer relay forwards encrypted packets and never decrypts traffic, while the connection-types reference documents WireGuard encryption across connection types. (Peer-relay encryption in Tailscale’s network account; Tailscale connection types and encryption)

What end-to-end encryption protects also matters for home-camera encryption.

This does not make the relay operationally invisible. It is still a host with an exposed UDP listener, network capacity, software updates and availability requirements. Treat its patching, access controls and monitoring as part of the deployment. Encryption protects traffic contents; it does not supply bandwidth or keep an overloaded relay available.

Peer relays provide a client-to-client forwarding path inside a tailnet. (Tailscale peer-relay guide) The GA announcement says this can replace subnet routers for many customers. Treat that as a deployment-specific option: verify the topology and the endpoints that need connectivity before changing an existing subnet-router deployment. (Tailscale GA announcement: deployment options)

Kubernetes has a separate operator requirement

The current Kubernetes guide requires Tailscale Kubernetes Operator 1.102 or later for its PeerRelay custom resource. It also requires an appropriate grant and a cluster/cloud environment that can supply a public UDP LoadBalancer Service. These are separate prerequisites from the general relay/client minimum. (Kubernetes PeerRelay guide)

The operator fronts each relay replica with a load-balancer endpoint and configures the advertised static endpoint from the assigned address. That gives peers a stable public UDP path when a pod restarts or reschedules. It does not remove the need to check firewall rules, security groups, load-balancer behavior and the location of the cluster relative to the participating devices.

Choose the standalone CLI approach for an ordinary host and the operator resource for a cluster that meets the documented prerequisites. Verify the current guide when upgrading; an older general-client minimum is not evidence that an older operator understands the custom resource.

Measure the gain and the relay’s capacity

A first-person account on the Tailscale blog reports a Delhi-to-Minneapolis test in which throughput increased from 2.2 Mbit/s through DERP to 27-35 Mbit/s through a peer relay, while round-trip latency fell from 452 ms to 298-306 ms. That is an attributed result on a particular path, with a particular relay placement. It illustrates a possible benefit without predicting the result on a new deployment. (How Tailscale Peer Relays saved my holiday: a 12.5X performance boost from India)

For an operational comparison, record the endpoints, network conditions, relay location, observed connection type and transfer workload. Compare both latency and sustained throughput, then repeat under concurrent demand. A relay that improves one lightly loaded transfer may become a bottleneck when several devices depend on it.

The client metrics reference lists peer-relay counters such as tailscaled_peer_relay_forwarded_packets_total and tailscaled_peer_relay_forwarded_bytes_total, along with the relay-endpoint metric. Use the documented metrics to observe traffic and endpoint states, and pair them with host and network monitoring. (Tailscale. “Client Metrics.” Tailscale Docs, 2026)

Feature behavior has evolved across releases. The Tailscale. “Changelog.” Tailscale, 2026 records relay throughput and stability fixes, along with peer-relay-aware ping-view changes. Consult the release notes for the versions being rolled out; a historical performance example is not a reason to pin the entire deployment to that example’s client version.

A useful rollout begins with one troublesome path and a bounded relay population. Keep DERP reachable, authorize only the devices that need the relay, verify the selected path, and expand only after measuring the end-to-end result and the forwarding host’s capacity. Peer relays give operators another path to control. The evidence for adopting one is an improvement on the actual network, with an owner able to keep the relay healthy.