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.
Editorial analysis by NHI Mgmt Group, based on content published by Tailscale: “How Tailscale Peer Relays saved my holiday: a 12.5X performance boost from India”.
By the numbers:
- The connection improved by 12.5X after enabling peer relays.
- Relay latency dropped from 452ms over DERP to 298ms on peer relays.
Key questions
Q: When should teams move remote access off shared relay fallback?
A: Teams should move high-volume or latency-sensitive administration off shared relay fallback when the relay becomes the bottleneck rather than the access path itself.
Q: Why does authenticated remote access still fail operationally over relays?
A: Authenticated remote access can still fail operationally when NAT traversal forces traffic through a shared relay that was built for reachability, not dedicated throughput.
Q: What breaks when direct peer-to-peer connections are not possible?
A: What breaks is not authentication, but the assumption that a secure session will also be a performant one.
Practitioner guidance
- Define relay fallback tiers Set policy for when shared DERP is acceptable and when a dedicated peer relay is required for administrative or data-heavy sessions.
- Provision an owned relay node Assign a well-connected node as a peer relay and size it for the throughput profile of your remote operations.
- Validate direct and relayed paths separately Use tailscale ping and throughput testing to confirm whether sessions are direct, peer-relayed, or falling back to shared DERP.
Bottom line: Shared relay fallback preserves availability, but it can cap throughput enough to disrupt ordinary remote administration.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:10 pm
Shared relay fallback is an availability control, not a performance control. The article makes clear that DERP keeps sessions alive when direct connections fail, but it does not guarantee the throughput needed for real administration work. That distinction matters for identity and access programmes because the access path is part of the operating model, not an implementation detail. Practitioners should treat fallback paths as governed infrastructure with explicit service expectations.
A question worth separating out:
Q: How should teams compare peer relays and shared DERP for remote access?
A: Compare them as two fallback classes, not as interchangeable features. Peer relays give you dedicated capacity on infrastructure you control, while shared DERP gives you broad availability when nothing else works. Teams should reserve shared DERP for universal reachability and use peer relays when they need predictable throughput for trusted internal workflows.
👉 Read our full editorial: Tailscale peer relays show the limits of shared relay capacity