DERP server usage refers to traffic that is relayed through Tailscale’s DERP infrastructure rather than flowing directly between peers. Monitoring this metric helps operators understand connectivity behaviour, identify relay dependence, and distinguish normal fallback from potential network performance issues.
What DERP server usage tells you about connectivity
DERP server usage is a signal about how often a network must fall back to relay traffic instead of completing direct peer-to-peer paths. That makes it a practical lens for understanding reachability, NAT traversal behaviour, and whether the network is operating in its ideal low-latency state.
In normal operation, some relay traffic is expected, especially when endpoints are behind restrictive firewalls or symmetric NAT. The key question is whether relay use is occasional and explainable, or persistent enough to suggest an underlying connectivity constraint that should be investigated.
When operators watch this metric over time, they are not just counting relayed packets. They are looking for a pattern that separates healthy fallback from a broader loss of direct connectivity, path instability, or environmental changes that affect peer discovery and traversal.
Why relay dependence matters
Relay dependence usually increases latency and can reduce the efficiency of otherwise direct network paths. It can also mask the true behaviour of the environment, because a system may appear connected even when the preferred direct route is unavailable or unreliable.
That distinction matters operationally because a high relay rate can point to firewall policy, routing asymmetry, DNS issues, endpoint mobility, or middlebox behaviour that interferes with direct establishment. It is often a symptom, not the root cause.
For practitioners, the useful interpretation is contextual: a spike after a topology change may be expected, while a sustained baseline may indicate that direct connectivity is not being achieved at all. In that case, DERP usage becomes a diagnostic signal for network health rather than just a usage statistic.
How to interpret the metric in practice
Read DERP server usage alongside direct peer success, connection stability, and any recent changes to firewall, VPN, or routing policy. A single percentage by itself rarely tells the full story, because the same relay rate can mean benign mobile connectivity in one environment and persistent failure in another.
Use the metric to separate normal fallback from structural reliance. If most traffic is repeatedly relayed, the environment may be over-constrained, or the direct path may be too fragile to support consistent peer-to-peer communication.
It is also useful to compare the metric across time windows and groups of endpoints. A narrow issue affecting one site, subnet, or class of device often points to a local network condition, while a broad shift across the fleet suggests a more systemic change.
NHIMG research on non-human identity risk shows why telemetry clarity matters: only NHI Mgmt Group’s Ultimate Guide to Non-Human Identities notes that only 5.7% of organisations have full visibility into their service accounts. The same principle applies here, because operators need enough visibility to tell whether fallback traffic is expected or a sign of a control problem.
How DERP usage fits into network and access governance
DERP server usage is not just a performance metric, it is also part of operational governance because it reveals how reliably endpoints can establish direct trust paths. When the fallback rate is high, teams may need to review connectivity policy, endpoint posture, or the assumptions built into remote-access design.
That is especially important in distributed environments where reliability, user experience, and control boundaries all depend on stable peer connectivity. The metric helps teams decide whether the current architecture is working as intended or whether the environment has drifted toward excessive relay dependency.
Used well, the metric supports a broader operational question: are we seeing deliberate fallback, or are we compensating for a hidden connectivity problem? Answering that question early can reduce troubleshooting time and prevent persistent inefficiency from becoming the new normal.
Risk and Threat Considerations
High or unexplained relay dependence can create operational risk because it may conceal degraded connectivity, increase latency, and make it harder to notice when direct paths are failing across large parts of the environment. If relay use is persistent, it can also become a sign that network controls or topology changes are unintentionally forcing traffic through a less efficient path.
Failure mechanism: Direct peer paths fail or become unreliable due to firewall policy, NAT behaviour, routing asymmetry, or environmental drift, so traffic silently falls back to relay infrastructure and the organisation loses visibility into the underlying connectivity problem.
Impact: Operators may accept a degraded state as normal, troubleshooting becomes harder, and widespread reliance on relays can increase latency and reduce confidence in the resilience of peer-to-peer communication.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | DERP relay reliance affects whether peer connectivity and trust paths are functioning as intended. |
| DE.CM — Security Continuous Monitoring | DERP usage is a monitoring signal that reveals connectivity behaviour and fallback patterns. | |
| Recommendation — Review access and connectivity controls to reduce unintended relay dependence. Track relay usage trends to detect unusual shifts in network path behaviour. | ||
| CIS Controls v8 | 12 — Network Infrastructure Management | Relay-heavy traffic often points to routing, firewall, or network path issues governed by infrastructure control. |
| Recommendation — Validate network path settings and firewall rules that force traffic through relays. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Least Privilege and Access Scope | Persistent relay use can indicate broader access-path design issues that increase operational exposure for non-human access paths. |
| NHI-10 — Visibility and Monitoring | The metric directly measures how often traffic is relayed instead of direct, making visibility central to the concept. | |
| Recommendation — Limit unnecessary access-path complexity and reduce reliance on compensating relay routes. Instrument relay metrics so you can distinguish normal fallback from path failures. | ||
Practitioner Guidance
What to watch for: Treat DERP server usage as a trend metric, not a point-in-time verdict. A short-lived increase after mobility, network changes, or endpoint churn may be benign, but a sustained rise should prompt review of firewall rules, route stability, and peer reachability.
Practitioner takeaway: The most useful response is to ask whether the relay is a deliberate fallback path or a sign that direct connectivity has stopped being reliable.
