Tailscale Throughput: Why It's Slow and How to Fix It

Slow Tailscale transfers almost always have one of four causes, and they are worth checking strictly in order because three of them are wasted effort until the first is ruled out. Tuning kernel offload on a machine whose traffic is going through a relay in another country is a good way to spend an afternoon and change nothing.

The order is: find out whether the path is direct, restore a direct path if it is not, then look at the endpoints, then look at what is in the middle.

Step 1: find out if you are relayed

This single check explains most complaints. Run it on either end:

tailscale status

Tailscale’s connection-types documentation defines what the peer column tells you. direct means a peer-to-peer UDP tunnel. relay means traffic is crossing a Tailscale-operated DERP server. peer-relay means another device inside your own network is forwarding it.

For a live view of a specific peer:

tailscale ping <peer-name>

Read the output patiently. The documentation notes that direct connections typically begin with DERP packets and then transition to a direct route with improved latency, so the first line or two travelling via DERP is normal. What matters is whether it upgrades. Persistent DERP or peer-relay entries that never switch are your answer.

The performance documentation is blunt about why this matters: direct connections “nearly always result in lower latency and higher throughput”. The connection-types page adds that DERP relays are “generally slower than direct connections and may offer lower maximum throughput” because quality of service on them is limited. Peer relay sits in between, usually faster than DERP by avoiding a geographically distant hop, but still an extra hop.

DERP is not a bug. It is the reason your connection works at all behind a hostile network, and the relay still cannot read the payload. It is just not where you want to live.

You can put rough numbers on the gap with the mesh latency and throughput estimator on this site, which models a baseline round trip against the relay detour and shows what each path type does to your ceiling.

Step 2: get back to a direct path

Direct connections need both peers to reach each other over UDP after a coordinated hole-punching attempt. When that fails, one of a small set of things is usually responsible.

UDP is blocked or throttled. Corporate networks, some campus networks and a fair number of hotel and carrier networks restrict outbound UDP or aggressively rewrite it. There is nothing to fix on the Tailscale side; the fix is a different network path, or accepting the relay there.

Symmetric NAT on one or both ends. Symmetric NAT allocates a different external port per destination, which defeats the address prediction hole punching relies on. Consumer routers in “strict” or “symmetric” NAT modes and many CGNAT deployments behave this way. If the router exposes an endpoint-independent or “full cone” mapping mode, that setting is the fix.

Double NAT. Two layers of translation, typically an ISP router in gateway mode plus your own router, compound the problem. Putting the ISP device in bridge mode removes a whole class of failure at once.

No dynamic port mapping. UPnP, NAT-PMP or PCP let a peer open the path itself. Many routers ship with all three off. Turning one on is often the entire fix for a stubbornly relayed home node.

A firewall policy you wrote. On a node you control, confirm outbound UDP is permitted and that any hairpinning restrictions are not blocking two internal peers from meeting via their external addresses.

For a server you actually control the front door of, forwarding a UDP port to it removes the guesswork entirely: with a reachable inbound path, peers connect directly rather than negotiating for it.

Step 3: fix the endpoints

Once a peer shows direct and it is still slower than the link should allow, the bottleneck has moved to the machines.

Turn on UDP offload on Linux forwarding nodes. This is the highest-value single change on the list. Tailscale’s performance documentation gives the command for Linux devices acting as exit nodes or subnet routers:

ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

Replace $NETDEV with the physical interface, not the Tailscale interface. The documentation states that transport-layer offloads enable UDP throughput improvements, and gives the requirements: Tailscale 1.54 or later, and Linux kernel 6.2 or later. The setting does not survive a reboot on its own, so persist it through your network configuration or a systemd unit.

Check kernel and client versions. The same documentation recommends kernel 6.2 or later to pick up current kernel features, and notes that recent operating system versions carry the most recent software and hardware optimisations. An old kernel on a router appliance is a common invisible ceiling.

Prefer clock speed over core count. The documentation is explicit that “higher CPU clock speed is more important than more cores”. WireGuard’s encryption work for a single tunnel does not spread usefully across many slow cores. A low-power NAS or single-board computer acting as your subnet router will cap throughput at its clock, and no configuration change moves that.

Watch for userspace networking mode. Tailscale documents this mode as the way to run “where you don’t have access to create a VPN tunnel device”, which it notes “often happens in container environments” because not every Linux system exposes /dev/net/tun; Heroku and Google Cloud Run are the examples it names. In that mode packet processing moves out of the kernel and into the client, which puts it on a different performance footing from a kernel TUN path and rules out the offload settings above entirely. Tailscale publishes no throughput figure for it, so treat it as a condition to identify and test rather than a known penalty: if a containerised node is your suspected bottleneck, establish which mode it is running in before tuning anything else, then measure it.

Step 4: fix what is in the middle

If the two endpoints are healthy and the path is direct, the remaining suspect is whatever is forwarding on their behalf.

The subnet router is a single machine. All traffic to an advertised range crosses one node, which means that node’s CPU, NIC and uplink are the ceiling for the entire subnet. Per Tailscale’s subnet documentation, a Linux subnet router also requires kernel IP forwarding to be enabled, and it is exactly the class of device that benefits from the offload command above. If a whole site feels slow, look at the router before looking at the clients.

The exit node is worse. An exit node carries every packet of a client’s internet traffic. It inherits that machine’s upstream bandwidth and its distance from wherever the client is actually going. Traffic that was previously a short hop can become a long detour. Exit nodes are a targeted tool, not a default, and a client left with one enabled is one of the most common causes of “everything got slow” reports.

Path MTU problems look like something else. The symptom is distinctive: small packets and handshakes work perfectly, large transfers stall or crawl. WireGuard adds header overhead to every packet, so the usable payload inside the tunnel is smaller than the underlying link’s. Tailscale sets a conservative interface MTU to survive most paths, but a link in the middle that silently drops fragmentation-needed messages will still break large flows. If ping works and file transfers hang, test with progressively larger payloads to find the cliff rather than assuming a bandwidth problem.

Measure it properly

Two rules keep throughput numbers honest.

Test both paths. Run the same transfer over the tailnet address and over the LAN address between the same two machines. The difference isolates the overlay from everything else. Testing only the tunnel tells you nothing about whether the underlying link was ever fast.

Test the direction you care about. Asymmetric uplinks are the norm on residential and many business connections, and a node with a 40 Mbps upstream will serve at 40 Mbps no matter how fast its download is. Reverse the direction of the test and see whether the number moves.

Use a real throughput tool such as iperf3 for this rather than inferring bandwidth from a file copy, which mixes in disk speed and protocol overhead.

The checklist in priority order

1. tailscale status on both ends. If the peer says relay, stop and fix that first.
2. Enable UPnP, NAT-PMP or PCP, or bridge the ISP router, or forward a UDP port to the node you control.
3. Re-check with tailscale ping and confirm the path upgrades to direct.
4. On Linux exit nodes and subnet routers, apply the UDP GRO forwarding settings and persist them.
5. Confirm Tailscale 1.54+ and kernel 6.2+ on those forwarding nodes.
6. Check whether the bottleneck node is running userspace networking or an underpowered CPU.
7. Confirm no client has an exit node enabled that it does not need.
8. If handshakes work and large transfers stall, investigate path MTU rather than bandwidth.
9. Compare tailnet throughput against LAN throughput, in both directions, with iperf3.

Most of this is decided at setup time. The Tailscale setup guide covers the configuration choices that avoid these conditions, how a Tailscale mesh VPN works explains why the coordination and data planes behave the way they do, and if the relay behaviour is pushing you to evaluate alternatives, Tailscale compared with ZeroTier and NetBird covers how the others handle the same problem.