tailscale login hangs forever

Not specified by the original author.

Fix tailscale login hanging forever

TL;DR: The login is stuck on wedged local state, not on the network. Delete /var/lib/tailscale/tailscaled.state, then run tailscale up and log in fresh.

The error

$ tailscale login
(hangs forever, no login link appears)

Logs show the client sitting in NeedsLogin state and going nowhere.

Fix it

1. Kill any stuck login attempt

Ctrl-C the hung command.

2. Delete the stale state file

sudo rm /var/lib/tailscale/tailscaled.state

This wipes the local login state. Your tailnet devices and settings in the admin console are untouched.

3. Log in fresh

sudo tailscale up

Expected: a login URL prints within seconds. Open it, authenticate, and the command completes.

4. Re-apply your flags

If you normally pass flags like --accept-dns=false, add them back after the first successful login. One reporter found the hang only happened when the flag was passed on a wedged state; after the state wipe, everything worked with or without flags.

Expected: tailscale status shows connected.

When this applies

• tailscale login or tailscale up hangs with no URL and no error
• Retrying and restarting the daemon do not help
• Logs show the client stuck in NeedsLogin

When it does not apply

• A login URL appears but fails in the browser (account/auth problem)
• tailscale up --auth-key fails immediately (key problem)
• The daemon itself will not start (see the daemon skills)

Tool compatibility

Tailscale on Linux with the standard state path. Reported on 1.88.x; the state-file layout is the same across 1.x.

Variant phrasings

tailscale up hangs the same way

Same root cause and same fix. login and up share the state file.

tailscale status says unexpected state: NoState

A related symptom reporters saw alongside the hang. The state wipe fixes this too.

Why it happens

The daemon persists login progress in the state file. If a previous attempt died mid-write or the stored credentials went stale in a way the client does not detect, every new login replays the same broken state instead of starting over.

Edge cases

• You will re-authenticate: deleting state logs the machine out. Keep a browser handy.
• Headless servers: use tailscale up --auth-key with a fresh auth key after the wipe instead of the interactive flow.
• It comes back: if logins hang again weeks later, something is corrupting state on shutdown; check disk health and unclean reboots.

Thread ref gh:tailscale/tailscale#9514 (open, 19 reactions). The reporter ran tailscale login and expected a login link, but the command hung indefinitely; logs showed the client shutting down and sitting in NeedsLogin state. A later reporter on 1.88.3 resolved it: after tailscale up --accept-dns=false hung, restarting did not help, so they ran sudo rm /var/lib/tailscale/tailscaled.state and logged in again without the flag, which finally worked; afterward even --accept-dns=false worked fine. Source: https://github.com/tailscale/tailscale/issues/9514

Not specified by the original author.

tailscale up on a headless server: "To authenticate, visit: https://login.tailscale.com/a/..."

TL;DR: on a headless box tailscale up cant open a browser, so it prints a login URL and waits. Either open that URL on your phone or laptop and approve the device, or skip the dance entirely with tailscale up --authkey [your auth key] using a reusable auth key from the admin console.

To authenticate, visit: https://login.tailscale.com/a/[code]

Steps

1. Start the join:

sudo tailscale up

Expected output includes the login URL shown above.

2. Open that URL on any device with a browser, sign in, and approve the machine. The command returns on its own once you approve.
3. Verify:

tailscale status

Expected: your node listed with a 100.x.x.x address.

4. Unattended path (scripts, rebuilds, containers): in the Tailscale admin console generate a reusable auth key, then:

sudo tailscale up --authkey [your auth key]

Expected: the node joins immediately, no URL printed.

When this applies

• headless servers, VMs, and containers where tailscale up prints the URL and waits
• first-time joins with no browser on the box
• automated provisioning where nobody can click approve

When it doesnt

• failed to connect to local tailscaled — the daemon isnt running; start the service first
• invalid key on --authkey — the key was single-use and already consumed; generate a reusable one
• nodes showing Logged out later — check key expiry in the admin console

Compatibility

Tailscale 1.x, Linux, macOS, Windows.

Why it happens

The CLI delegates identity to the browser-based control-plane login. With no browser the out-of-band approval URL is the only channel, and auth keys exist precisely for the no-human case.

Edge cases

• keys expire: set a long expiry for servers or rotate on a schedule
• in Docker, pass the key as the TS_AUTHKEY env var instead of baking it into the image
• after tailscale up --reset you may need to re-approve the device

Find this skill again

curl -s 'https://vectle.com/api/v1/search?q=tailscale+up+headless+authenticate+visit'

Tailscale users setting up headless servers found sudo tailscale up prints To authenticate, visit: https://login.tailscale.com/a/... and then waits with no browser on the box. The verified fixes: approve the printed URL from any device with a browser, or for unattended setups use tailscale up --authkey with a reusable auth key from the admin console, then confirm with tailscale status. Source: https://github.com/tech-drew/home-lab-mini-rack/blob/HEAD/v1-lego-infrastructure-prototype/docs/networking/tailscale-setup.md

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.