What Are the Warning Signs That a Tunnel Relay Is Limiting Throughput?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

What Are the Warning Signs That a Tunnel Relay Is Limiting Throughput? - Zima Store Online

A relay is probably limiting throughput when the connection stays relayed and improves sharply on a direct or closer path while both endpoints remain underused.

Overlay VPNs and outbound tunnels often fall back to a shared or self-hosted relay when NAT traversal cannot form a peer-to-peer path. The relay may preserve connectivity but add another network leg, queue, TCP or TLS layer, geographic detour, fairness cap, and processing point. Reliable diagnosis compares relay status, latency, jitter, direction, endpoint CPU, and a direct-path control instead of blaming encryption or the NAS from one slow file copy.

Confirm That the Data Path Is Actually Relayed

Check the tunnel client’s peer status while traffic is active. Record whether the path is direct, relayed, proxied, or switching between modes, plus the relay region or host selected.

A Tailscale issue documents cellular clients remaining on DERP with latency ranging from 200 to 900 milliseconds. A connected status therefore proves reachability, not an efficient data path.

If the client reports direct connectivity throughout the slow test, do not label the relay as the cause. Continue with endpoint CPU, tunnel offloads, MTU, ISP upload, Wi-Fi, and storage tests.

Compare Relayed and Direct Paths With the Same Endpoints

Run a network-only throughput test between the same client and home server while relayed, then repeat after establishing a direct peer path or a temporary port-reachable test network. Keep protocol, direction, and endpoint hardware unchanged.

A published peer-relay case measured both a large latency reduction and a 12.5-fold throughput increase after changing only the relay topology.

A large and repeatable improvement after removing or relocating the relay is strong evidence. A small change means the relay may not be the dominant bottleneck, especially when the home upload or remote Wi-Fi already sets a lower ceiling.

Watch for High Latency, Jitter, and Geographic Detours

Measure minimum, median, and high-percentile latency to the peer and to the relay region. Record jitter and packet loss during idle periods and during a sustained transfer.

An independent diagnostic report captured a relayed path with average latency above 400 ms, substantial jitter, and measurable packet loss, a combination that can make TCP file transfers and interactive access collapse even when the tunnel remains established.

If the relay is geographically far from both endpoints or latency swings widely under load, test a closer region, self-hosted relay, or peer relay. Stable low relay latency with poor throughput points more toward capacity, fairness, CPU, or transport behavior.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

Check Whether the Relay Has a Consistent Throughput Ceiling

Run several large transfers at different times and in both directions. A relay limit often appears as a stable plateau that does not rise when endpoint internet speed, NAS storage, or client Wi-Fi improves.

Benchmark work on relay implementations shows that forwarding capacity, CPU efficiency, and concurrent load materially affect tunnel throughput. A current DERP-compatible project publishes multi-load relay benchmarks across CPU sizes and traffic levels.

If one stream plateaus, add a second controlled stream and observe total throughput. A fixed shared ceiling suggests relay or path capacity; unchanged low throughput with idle relay CPU suggests RTT, loss, congestion control, or endpoint constraints.

Separate Relay Limits From Endpoint CPU and ISP Upload

Monitor CPU, soft interrupts, encryption process use, NIC utilization, and disk activity at both endpoints and the self-hosted relay. Compare the slow direction with the home connection’s measured upload and download capacity.

A relay can only forward as fast as its slowest inbound or outbound leg. Running the relay on a low-tier VPS, distant region, constrained container, or shared home uplink may reproduce the same symptom as a managed-relay cap.

If endpoint or relay CPU reaches saturation, tune or upgrade that node before changing relay geography. If CPU is low but one ISP direction is full, the relay is exposing the access-link limit rather than creating it.

Change the Relay Design at the Stop Boundary

Replace the relay path when it remains selected for normal traffic, creates unacceptable latency or jitter, caps sustained throughput below the workload requirement, and a direct or closer relay control proves the rest of the path can perform better.

The ZimaSpace guide to CGNAT remote-access alternatives explains why a relay may be necessary even when it is not the fastest path.

Choose a closer peer relay, better-positioned VPS, improved NAT traversal, or lower-bandwidth workflow rather than disabling the only reachable path without a replacement. Validate the new design with the original remote file, media, or sync workload, not only a short ping.