Tailscale Connected but Relayed? Check Direct vs DERP Paths and Fix Slow Connections

What happened​

Onyimadu's status line kept coming back as relay, but the same connection switched to direct on his home Wi-Fi. That made the café network the likely culprit. In his account, tailscale status showed a Paris relay and tailscale ping returned about 40 ms per reply. Once the connection went direct, ping dropped to about 12 ms. These are the author's own observations, not independent measurements. They fit a network-related explanation, but they don't prove the café was the only cause.

The three connection types​

Tailscale's documentation lists three connection types:

• Direct: devices send UDP packets straight to each other.
• DERP relayed: traffic passes through Tailscale's relay servers.
• Peer relay: traffic passes through another device in your tailnet that you've set up as a relay.

All three are end-to-end encrypted with WireGuard. Tailscale says the main difference is performance, not security. Direct connections usually give the lowest latency and highest throughput. Relays are the fallback.

The MakeUseOf piece only compares direct and DERP, so it leaves peer relay out.

Relays don't expose your data​

DERP servers forward packets that are already encrypted. Tailscale says they can't decrypt your traffic. The cost of a relay is speed, not privacy.

Every connection starts on a relay​

Tailscale's docs say all connections start relayed through DERP, and Tailscale then tries to upgrade them to direct. If that fails, it tries a peer relay. If there is none, the connection stays on DERP. Tailscale also periodically re-checks whether a better path is available.

So seeing a relay for a moment is normal. Seeing one that never goes away is the thing to investigate.

How to check your own connections​

1. Run tailscale status while the two devices are talking. Look at the peer's line. Tailscale's documentation says direct followed by an address means a direct connection. relay followed by a location code, such as "sea" or "tor", means DERP. peer-relay means a peer relay. If there is no relay entry for that peer, the traffic isn't going through DERP.
2. Run tailscale ping <device-name>. Read the route in each reply. A reply that says via DERP(...) is relayed. A reply that says via <address>:<port> is direct. Tailscale's troubleshooting guide says the command keeps trying until it sends 10 pings through relays or finds a direct path. A few relayed replies followed by a direct one is the normal pattern. A relay on every reply, ending in "direct connection not established", is the case to dig into.
3. Run tailscale netcheck. Its output includes whether the device supports UDP or port mapping, plus latency to the nearest DERP servers. Tailscale's device connectivity docs describe a field called MappingVariesByDestIP as the most important field for working out why a device isn't using direct connections.
4. Test from another network. Move one device to a phone hotspot, or compare home against office or café Wi-Fi, and repeat the ping. If the route changes with the network, the network is your lead.

Tailscale's guidance on poor performance offers a way to narrow it down. If a device only ever uses relay connections, it likely can't establish direct ones. If it uses both, the NAT traversal problem likely originates from the other device.

Why a network forces a relay​

Tailscale's documentation names two common blockers:

• Blocked UDP. Direct connections need UDP in both directions. If a network blocks it, devices can still connect through a relay, but not directly.
• Hard NAT. This means a gateway that gives each outbound connection its own port mapping, with an external port that outsiders can't predict. Tailscale says it can't establish a direct connection if both devices are behind hard NAT. Cloud NAT gateways, such as AWS's, can behave the same way.

Both ends matter. The network conditions and NAT types on both sides of a connection decide whether Tailscale goes direct or relayed.

A caveat on the "strict café" explanation​

A strict public network is a plausible suspect. But a relay label alone doesn't tell you which router or firewall caused it. One third-party guide puts it plainly: a relay label does not identify which router caused it.

The MakeUseOf article also says a strict network on one side paired with an ordinary home network can force a relay. Tailscale's wording is more careful. Hard NAT is a problem when both devices are behind it. Treat that line of the article as a rule of thumb, not a guarantee.

The symptom table, with caveats​

The article offers a rough symptom-to-cause table:

The author says most setups he's seen fit one of these. It's a useful checklist, not a diagnosis.

Fixes to try, in a sensible order​

1. Rule out the network. Do the hotspot test first.
2. Check the UDP port. Tailscale's docs say opening UDP port 41641 on a device's public IP helps direct connections where possible. That is the default port, and it can be changed, for example by passing --port=<number> to tailscaled. Confirm your actual port before you write a firewall rule.
3. Consider NAT-PMP or UPnP on your router. Tailscale says these give it more predictable, reachable ports. They are network-administration changes, so follow local security policy before turning on automatic port mapping.
4. Look at double NAT. The article suggests putting an ISP box into bridge mode so only one device does NAT. That is a reasonable idea, but Tailscale's documentation doesn't endorse bridge mode specifically. Look at your actual setup and ISP rules first.
5. Check the endpoint. Look for a local firewall, security software, or another VPN client on the affected device.
6. If relays are unavoidable, set up a peer relay. Tailscale's docs say peer relays are generally faster than DERP and run inside your own infrastructure. They still add a hop compared with a direct path. This is the option for cloud NAT gateways and similar cases. One third-party guide says peer relay needs Tailscale 1.86 or later on both the relay and the client devices. Check Tailscale's own docs for the current requirement.

Don't count on any of this working everywhere. Hotel, café and carrier networks may never allow direct paths, and port forwarding won't change that.

When a relay is fine​

The author says that for light jobs, such as SSH or a dashboard, a relay is fine. Heavier work, like big file transfers, may suffer. Tailscale's docs make the same distinction in more general terms. They call relayed connections when a direct one would be possible the most common cause of performance issues between tailnet devices. If your relayed path is stable and fast enough for the job, you don't need to fix it.

Takeaways​

• "Connected" in Tailscale doesn't mean "direct." Check with tailscale status and tailscale ping.
• A few relayed pings at the start are normal. A permanent relay is the signal to investigate.
• Use tailscale netcheck and a second network to work out which side is the problem.
• Relays cost you speed, not privacy.
• Open the UDP port, or use UPnP or NAT-PMP, only where your policy allows. Bridge mode needs a look at your actual setup first.
• For recurring relays you can't fix, a peer relay may be a better answer than living with DERP.

The author's café experience is anecdotal, but it matches Tailscale's documented behavior. This is a five-minute check that is worth running on any remote machine you rely on.