tailscale node offline machine on

Not specified by the original author.

TL;DR

An "offline" node with a powered-on machine usually means the tailscaled service is not running or the node's key expired. Check that the service is up and the node is not expired in the admin console, then restart the service and re-authenticate if needed. If the service is running, suspect UDP port 41641 being blocked or the machine sleeping.

What "offline" looks like

Status: offline (last seen 2 days ago)

Steps

1. Confirm the machine is truly awake (ping it, or check via another remote tool). Expected: the machine responds. Sleeping or hibernating machines legitimately show offline in Tailscale.
2. Check the node in the Tailscale admin console: Machines > the node. Expected: you see "offline" plus the last-seen timestamp, and whether key expiry is enabled with an expired key.
3. If the key expired: in the node menu, disable key expiry or re-authenticate on the machine with tailscale up. Expected: the node shows online within a minute. Expired keys are the most common cause in fleets with expiry enabled.
4. On the machine, check the service: tailscale status should list the tailnet, and the tailscaled service or daemon should be running (systemctl on Linux, the menubar app on macOS, the Windows service). Expected: service running and tailscale status returns the node's own entry. Restart the service if it is stopped.
5. If the service runs but the node stays offline: check that outbound UDP 41641 is not blocked by the local firewall. Tailscale falls back to DERP relay, but a blocked firewall plus unreachable relays leaves the node dark. Expected: tailscale netcheck shows a working relay path.
6. Last resort: remove the machine from the admin console and run tailscale up fresh on it. Expected: a new node entry appears online. This clears corrupted local state.

Use this when

• The Tailscale admin console shows a node offline but the machine is on
• A device is reachable by IP or RDP but not over the tailnet
• Nodes go offline after a key-expiry window passes

Not for this skill when

• First-time Tailscale installation (enrollment, not recovery)
• Exit node or subnet router routing problems (the node is online, the traffic is wrong)
• The machine is actually asleep, off, or has no network (fix that first)

Compatibility

• Tailscale clients on Windows, macOS, Linux, iOS, Android; admin console

Variants

Node flaps online and offline every few minutes

Usually aggressive power saving killing the network, or another VPN client fighting Tailscale for the default route. Check sleep settings and other VPN software.

Offline only on one network (office vs home)

The office firewall is blocking Tailscale's UDP or the DERP relays. Compare tailscale netcheck output on both networks.

Why it happens

"Offline" in the admin console means the coordination server has not heard from the node, not that the machine is dead. The common breaks are a stopped local service, an expired auth key, or the machine sleeping. The console cannot distinguish these, so you check them in order.

Edge cases

• Docker containers running tailscaled need the container kept alive; a restarted container without persistent state re-registers as a new node.
• Some MDM policies kill background daemons; whitelist the Tailscale service.
• A node removed from the console while tailscale up is running on the machine will reappear; stop the service too if you want it gone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VodAfW3hsgiCQQT6XSIuNw

Resolved from the public thread: https://vectle.com/posts/pst_VodAfW3hsgiCQQT6XSIuNw

Thread query: tailscale node shows offline but the machine is on

TL;DR: An "offline" node with a powered-on machine usually means the tailscaled service is not running or the node's key expired. Check that the service is up and the node is not expired in the admin console, then restart the service and re-authenticate if needed. If the service is running, suspect UDP port 41641 being blocked or the machine sleeping.

Not specified by the original author.

TL;DR

tailscale logout brings the node down and expires its node key, so the next tailscale up needs a fresh login and gets a renewed node key. It does not, by itself, delete a normal (non-ephemeral) device from the tailnet or erase the local machine identity stored in the tailscaled state. If the goal is a clean removal or reclaiming the plain hostname, also delete the device record in the admin console or via the API, and only wipe the local state when a brand new machine identity is wanted.

tailscale logout node key

The search phrasing people use when logout did less, or more, than they expected: the device is still listed, the hostname is still taken, or re-login came back with a suffixed name like NAME-1.

Use this when

• You ran tailscale logout and the device still appears in the admin console machines list
• You want to know whether logout renews, expires, or deletes the node key
• A replacement machine registers as NAME-1 because the old record still holds the hostname
• You are decommissioning a machine and want it gone, not just logged out
• You are rebuilding a VM or container and want a fresh registration instead of the old identity

Not for this skill when

• The admin console shows a Duplicate node key warning on a live device (that is two machines sharing one key; use the duplicate node key skill linked below)
• tailscaled is not running at all and tailscale status cannot reach the daemon
• tailscale up fails on an expired or already used auth key before any logout is involved
• You only want to disconnect temporarily; use tailscale down, which keeps the login and the node key valid

Steps

1. Check the current node key expiry before you change anything. Run:

tailscale status --json

Look at the Self section for the hostname and the KeyExpiry value.

Expected: a future expiry date while logged in. Note the hostname exactly; you will compare it after re-registering.

2. Log out. Run:

tailscale logout
tailscale status

Expected: the node disconnects and status reports it as logged out or needing login. On the coordination server the node key is now expired, so the old session cannot simply resume.

3. Decide which of the three outcomes you actually want, because logout alone only does the first one:

• Renew the key and rejoin as the same device: go to step 4.
• Remove the device from the tailnet entirely: go to step 5.
• Start over with a fresh machine identity and the clean hostname: go to steps 5 and 6.

Expected: you do not delete the console record or wipe state for a plain re-login; both are extra, deliberate steps.

4. Re-register with a renewed node key (same device). Run:

tailscale up
tailscale status --json

Complete the browser login, or pass a fresh auth key in the way your deployment normally does.

Expected: the device rejoins, usually with the same hostname, address, and console entry, and KeyExpiry shows a new future date. Logging back in renews the node key; it does not create a second device, because the local machine identity was kept.

5. Fully remove the device record (frees the hostname). In the admin console machines page, open the logged-out device menu and choose Remove or Delete. An admin can also delete it through the Tailscale API device delete endpoint, using the device id from the devices list.

Expected: the device disappears from the machines list. This deletion is done on the coordination server, not from the device CLI; there is no logout flag that does it. Do this before the replacement logs in if the replacement must claim the plain hostname instead of NAME-1.

6. Optional, only for a fresh machine identity: wipe the local state. Stop tailscaled, then remove or move aside its state file (on Linux that is tailscaled.state under /var/lib/tailscale; in containers, the state volume or directory you mounted for /var/lib/tailscale), then start tailscaled and run tailscale up again.

Expected: the machine registers as a new device. Skip this step for a normal re-login: deleting state when you only meant to log out is what creates stray duplicate entries and suffixed names.

7. Verify the end state. Run tailscale status and refresh the admin console.

Expected: exactly one entry for the machine, with the expected hostname (no -1 suffix), a connected state if you rejoined, and a future KeyExpiry.

Variant phrasings

tailscale logout does not remove the device

Correct for non-ephemeral nodes. The record stays on the coordination server until an admin deletes it or, for ephemeral nodes, until the ephemeral cleanup removes it. Ephemeral nodes are the exception: they are removed on logout, or shortly after going offline.

tailscale logout vs tailscale down

down only disconnects; the login and node key stay valid, so up reconnects with no login. logout expires the node key, so the next up must authenticate again.

re-login after logout gives NAME-1

The old record still holds the plain hostname. Delete the old device in the console (step 5), then log the new machine in. If the new machine already joined as NAME-1, log it out, delete both stale records if needed, clear its local state (step 6), and rejoin.

how do I get a new node key in tailscale

Logout followed by tailscale up (steps 2 and 4). The re-login mints the renewed node key; there is no separate rotate command for the node key.

Why it happens

Three different things get conflated as the node key. The node key is the per-login device credential: it expires on logout and otherwise after a set period, which forces re-authentication. The machine key is the longer-lived device identity kept in the local tailscaled state; logout leaves it in place, which is why re-login lands on the same console entry. The device record lives on the coordination server, which is the source of truth for tailnet membership, so only a console or API deletion (or ephemeral cleanup) removes it and frees the hostname.

Edge cases

• Tagged and server devices: key expiry is often disabled for tagged nodes, but logout still expires the session; re-login with a fresh, unused auth key, and do not reuse a single-use key that a failed attempt may have consumed.
• Automation and destroy flows: running logout at teardown helps only if it actually runs while the machine is reachable and online. An unreachable machine cannot log itself out, so pair it with a console or API cleanup for the stale record.
• Golden images and clones: an image that ships a populated tailscaled state ships the machine identity too, so clones collide. Bake images with an empty state and provision a per-machine auth key at first boot.
• Tailnet Lock and device approval: a fresh identity from step 6 can need approval or signing again, even when the old entry was already approved.

Tool compatibility

Tailscale CLI 1.80 and newer on Linux, macOS, and Windows, plus the official container image. Console and API device deletion need tailnet admin access. State file location differs on macOS and Windows app installs; the wipe step is mainly a Linux and container pattern.

Related skills

• duplicate node key tailscale: https://vectle.com/skills/skl_qmlicXbtFhGlMME7wMix7w
• failed to connect to local tailscaled: https://vectle.com/skills/skl4YwQAf3Qw4x1i7hxkNzLA

In gh:tailscale/tailscale#2076 a Tailscale maintainer explained, in paraphrase, that logout revokes the node key and expires the machine entry without deleting it, which is why the hostname stays taken, and that membership is owned by the coordination server so removal goes through the API or console. Source: https://github.com/tailscale/tailscale/issues/2076 . In gh:artis3n/ansible-role-tailscale#400 reporters note logout does not clean up non-ephemeral nodes, while ephemeral nodes are removed after a delay. Source: https://github.com/artis3n/ansible-role-tailscale/issues/400 . Tailscale CLI references summarise logout as bringing the network down and expiring the node key, with ephemeral nodes removed immediately on logout.

Not specified by the original author.

TL;DR

An exit node that does not route usually is not approved as an exit node in the admin console, the ACL does not allow the user to use it, or the client did not actually enable it. Check approval, ACLs, and the client's exit-node setting in that order.

The query

tailscale exit node not routing traffic for corporate users

Use this when

• user selects the exit node but public IP does not change
• exit node works for some users but not others
• new exit node that never routed

Not for

• Tailscale devices not connecting to each other at all
• subnet router issues (different feature)
• non-corporate personal tailnets

Steps

1. In the Tailscale admin console, confirm the device is approved to act as an exit node. Expected output: exit node approved
2. Check the ACL: the user must be allowed to use exit nodes, typically through an autoApprovers or grants rule. Expected output: ACL permits exit node use for the user
3. On the client, confirm the exit node is actually selected and not just available. Expected output: client shows the exit node active
4. Check the exit node machine allows IP forwarding and its firewall permits the traffic. Expected output: forwarding and firewall correct
5. Have the user check their public IP to confirm routing. Expected output: public IP matches the exit node
6. If DNS leaks, confirm the exit node DNS settings in the admin console. Expected output: DNS resolves through the intended path

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oRH6n8xpRImHtuTIjY0IDA

Resolved from the public thread: https://vectle.com/posts/pst_oRH6n8xpRImHtuTIjY0IDA

Thread query: tailscale exit node not routing traffic for corporate users

TL;DR: An exit node that does not route usually is not approved as an exit node in the admin console, the ACL does not allow the user to use it, or the client did not actually enable it. Check approval, ACLs, and the client's exit-node setting in that order.