2026年11月14日

Tailscale Connection Unstable? Check DERP Relay, NAT, MTU, Key Expiry

IP Addresses & Routing

This article is a localized edition of the Japanese original. Read the Japanese original

When your Tailscale connection is unstable, the quickest first step is to use tailscale ping to find out whether you are connected directly to the other device or going through a relay server (DERP). Most slow or occasionally freezing connections happen over a relay, while a sudden complete loss of connectivity is more often caused by an expired key or by a DNS or route conflict. This article shows how to check the status, then explains the causes in the order they are most likely to occur, along with how to check and fix each one.

The commands focus on those common to the Tailscale client on Linux, macOS, and Windows. The output format of commands and the labels in the admin console can change between versions (as of October 2026), so also check tailscale --help for the version you have. Before changing server settings, make sure you can still get in by a route other than Tailscale (a console or a separate SSH path). If you make a mistake on a server that you can reach only through Tailscale, you will lock yourself out.

First, Sort the Symptom into One of Three Types

Even if you call it "unstable", the symptoms look different depending on the cause. Deciding which one yours resembles first narrows down what to investigate.

Slow, high latency, or occasional drops: going through a relay, poor line quality, or an MTU problem
Stops working at regular intervals, or suddenly one day: an expired key, being logged out, or an ACL change
Only certain destinations or certain kinds of traffic fail to arrive: overlapping subnet routes, a DNS (MagicDNS) conflict, or a firewall

Commands to Check the Status

The following three tell you most of what you need to know about the current state.

# List of devices that have joined, and the state of each
tailscale status

# Check the path to another device (its name or a 100.x.y.z IP)
tailscale ping web-server

# State of your own connection (whether UDP works, the NAT type, the nearest relay server)
tailscale netcheck

If the result of tailscale ping contains DERP, as in via DERP(tok), you are going through a relay; if an IP and port appear, as in via 203.0.113.5:41641, it is a direct connection. It is normal for the first few pings to go through a relay and then switch to a direct connection. If it stays on DERP no matter how many times you run it, there is a reason it cannot connect directly.

In tailscale netcheck, look at whether the UDP item shows that it is unavailable (false) and whether MappingVariesByDestIP is true. If the latter is true, you are behind a NAT that changes the external port for each destination (behavior close to a symmetric NAT), which makes direct connections difficult.

On Linux, you can also check the log of the client itself (tailscaled).

sudo journalctl -u tailscaled --since "1 hour ago"

Cause 1: Not Connecting Directly, Going Through a Relay (DERP)

This is the most common cause of the symptoms "slow" and "drops". DERP is a relay of last resort when a direct connection is impossible; it is easily affected by congestion and adds latency.

The main reasons a direct connection fails are as follows.

Both devices are behind a NAT that changes the port for each destination (more likely on mobile connections, with some routers, and in carrier-grade NAT environments)
A network such as an office or hotel network blocks UDP traffic
The server-side firewall blocks incoming Tailscale UDP traffic

The fix is to make one of the two devices reachable "from outside over UDP".

For a cloud VM or VPS, allow incoming traffic on Tailscale's UDP port (41641 by default) in the security group or firewall
For a router at home or in the office, consider enabling UPnP or NAT-PMP, or forwarding UDP port 41641 to that device
On a network where the sending side blocks UDP, users often cannot change it, so in that environment use it on the assumption that you will go through a relay

After changing the settings, run tailscale ping again and confirm that it has switched to a direct connection. The related articles also cover the NAT traversal mechanism itself in detail.

Cause 2: The Key Expired or You Were Logged Out

This is the first thing to suspect when "it suddenly stopped working one day". A Tailscale device key has an expiry, and by default you must log in again after a certain period (about 180 days). Once the key expires, the device is in the same state as if it had been removed from the tailnet.

Check whether tailscale status shows an expiry for the device in question, and check the expiry display in the device list in the admin console.

For PCs and smartphones that people use, logging in again restores the connection
For devices that run unattended, such as servers, you can disable key expiry for just that device in the admin console. However, a device with expiry disabled can keep being used if it is stolen, so limit it to the devices that need it and delete the device when it is no longer needed

Re-authentication may also be required if there was a password change or an account suspension on the SSO side (an account such as Google or Microsoft).

Cause 3: MTU Mismatch, Only Large Transfers Stop

If ping works and SSH login works, but only file transfers or large pages freeze partway, the cause may be MTU. The Tailscale interface uses a smallish MTU of 1280 by default, but this can happen if a link along the path (such as inside PPPoE or another VPN) passes only an even smaller value, or if ICMP is blocked along the path so that MTU adjustment does not work.

Check with pings of different sizes.

# Linux: forbid fragmentation and see whether a packet of the given size gets through
ping -M do -s 1200 100.101.102.103
ping -M do -s 1252 100.101.102.103

If small sizes get through and responses stop once the size grows past a certain point, it is an MTU problem. Check the MTU setting of the line outside Tailscale (the physical line side), and whether you have stacked VPNs on top of each other.

Cause 4: Conflicts with Other VPNs and Networks

Overlapping IP address ranges: Tailscale uses the 100.64.0.0/10 range. This range is reserved for carrier-grade NAT, and if your line contract or another VPN uses the same range, the routes collide and certain destinations become unreachable. Use ip route (route print on Windows) to check whether there are multiple routes for the same range
Overlapping subnet router routes: if the office LAN range advertised by a subnet router (for example, 192.168.1.0/24) is the same as the LAN at the home of the connecting side, the home side takes priority and traffic does not arrive. Review the advertised range, or change the range of one of the LANs
DNS conflicts: when you use MagicDNS, the device's DNS settings are rewritten by Tailscale. If name resolution becomes unstable because of a fight with the internal DNS or the DNS of another VPN, you can isolate the problem by making only that device stop accepting Tailscale's DNS settings (--accept-dns=false)
Using another VPN client at the same time: when multiple VPNs rewrite each other's routes, things become unstable. Stop one of them and compare

Cause 5: Power Saving or Sleep Stops the Connection

On smartphones and laptops, Tailscale traffic may stop while the screen is off or the device is asleep, and the connection may not work for a while right after waking. Check whether the OS power-saving settings restrict the Tailscale app's background activity. On devices used as servers, disable OS sleep.

Cause 6: The Client Is Outdated, or the ACL Changed

Older client versions may lack improved NAT traversal handling and bug fixes. If the instability continues, first update all devices to the latest version and then compare.

Also, when someone changes the ACL (access control policy) in the admin console, traffic to certain devices or ports can suddenly stop arriving. Check the ACL change history and see whether the time of the change matches the time the symptom appeared.

It may also be an outage of the whole service, so if no device can connect, check Tailscale's official status page too.

Also Check the Server-Side Firewall

If you use UFW or similar on a Linux server, you need to decide how to handle traffic from Tailscale's virtual interface (tailscale0). For example, to restrict SSH to Tailscale only, allow only port 22 from tailscale0, as follows.

sudo ufw allow in on tailscale0 to any port 22 proto tcp

Before changing the settings, confirm that you can get in by a route other than Tailscale, and then apply them.

Summary

First use tailscale ping to check whether the connection is direct or through a relay (DERP), and use tailscale netcheck to look at the UDP and NAT state
If it is slow or drops, aim for a direct connection by making one side reachable from outside on UDP port 41641
If it suddenly will not connect, check for an expired key and for ACL changes
If only large transfers stop, suspect MTU; if only certain destinations are unreachable, suspect a route or DNS conflict
Before changing settings, secure a way in other than Tailscale

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)