Notifications
Clear all
Topic starter
02/08/2026 12:04 pm
TL;DR: Relay choice can make or break remote access performance, with a Delhi-to-Minnesota test improving from 2.2 Mbits/sec over shared DERP to 27.5 Mbits/sec on peer relays, according to Tailscale. The lesson for identity and access teams is that connectivity fallback paths now need governance, not just availability.
NHIMG editorial — based on content published by Tailscale: How Tailscale Peer Relays saved my holiday, a 12.5X performance boost from India
By the numbers:
- The article reports a 12.5x improvement after peer relays were enabled.
Questions worth separating out
Q: How should teams handle access when direct connections keep failing across NATed networks?
A: Treat repeated relay fallback as an operational control problem, not a one-off connectivity annoyance.
Q: Why do shared relays become a bottleneck for remote administration?
A: Shared relays preserve connectivity, but they also inherit contention, distance, and provider-level fairness limits.
Q: What breaks when relay usage is invisible to the operations team?
A: Teams lose the ability to explain why a session feels slow, why a connection never upgrades to direct, or why some regions consistently perform worse than others.
Practitioner guidance
- Measure relay fallback under real network conditions Run repeated connection tests from the locations your admins and operators actually use, then record when sessions stay direct, switch to DERP, or upgrade to a peer relay.
- Define which devices may use dedicated relays Apply ACLs so only the systems that genuinely need relay-based reachability can use those nodes.
- Place relays where bandwidth is predictable Choose relay nodes with stable uplink capacity, low contention, and sensible geography relative to your user base.
What's in the full article
Tailscale's full post covers the operational detail this post intentionally leaves for the source:
- iperf3 test output and the before-and-after throughput measurements from Delhi to Robbinsdale
- Step-by-step peer relay setup, including relay port configuration, router port forwarding, and ACL grants
- tailscale ping output showing the transition from DERP to peer-relay paths in practice
- Static endpoint override guidance for more complex relay discovery environments
👉 Read Tailscale's analysis of peer relays and DERP throughput limits →
Tailscale peer relays: what they change for remote access performance?
Explore further
02/08/2026 1:10 pm
Relay path selection is now a governance issue, not just a connectivity issue. When direct paths fail, organisations inherit a fallback architecture that can reshape performance, reliability, and operational trust. That matters because the control plane for access is only as strong as the least predictable transport path. Practitioners should treat fallback relays as part of the access architecture, not as invisible plumbing.
A question worth separating out:
Q: What should organisations consider before deploying their own peer relays?
A: Account for port exposure, relay placement, ACL scope, and the operational ownership of capacity. A peer relay can improve throughput, but it also introduces a node that must be maintained, monitored, and governed as part of the access path. The right question is not whether to relay, but which sessions deserve dedicated control.
👉 Read our full editorial: Tailscale peer relays show the limits of shared relay capacity
