tailscale up

Not specified by the original author.

TL;DR

This error means the tailscaled daemon is stopped: the tailscale command you type is only a client, it talks to the daemon over a local socket, and every client command fails this way when the daemon is not running. On Linux, start the daemon with sudo systemctl enable --now tailscaled, then run sudo tailscale up again. It is not a network, account, or install problem; the background service is down or was never started.

failed to connect to local tailscaled; it doesn't appear to be running (sudo systemctl start tailscaled ?)

Use this when

• Any tailscale command (up, status, ping) fails with failed to connect to local tailscaled
• The message suggests starting tailscaled with systemctl and you are on Linux
• The same failure appears on macOS, Windows, or a snap install, where the daemon runs as an app, a service, or a snap instead

Not for this skill when

• tailscale status works but shows NeedsLogin. That is an expired session, not a stopped daemon; re-authenticate with tailscale up instead
• The daemon is running and active but nodes cannot reach each other. That is a connectivity or ACL problem, not this one

Steps

1. Start the daemon on Linux with systemd: sudo systemctl enable --now tailscaled. This starts it now and keeps it enabled across reboots.

Expected: no output, which means success.

2. Confirm it stayed up: systemctl is-active tailscaled.

Expected: active. Anything else means the daemon started and died; go to step 4.

3. Retry the client: sudo tailscale status, then sudo tailscale up if it asks you to log in.

Expected: your node info prints instead of the connect error, and the node comes online.

4. If the service will not stay up, read the log: journalctl -u tailscaled -n 50. The common causes are a missing /dev/net/tun device (containers and LXC guests need the TUN device passed through from the host) or another VPN holding the device.

Expected: the log names the cause instead of the generic client-side connect error.

5. On other platforms, start the equivalent service. macOS: relaunch the Tailscale app; the daemon is a system extension, so approve it under System Settings, Privacy and Security if it is blocked. Windows: start the Tailscale service in services.msc. Snap installs: sudo snap restart tailscale.

Expected: the client commands in step 3 succeed on that platform too.

Variant phrasings

tailscaled doesn't appear to be running

The same stopped-daemon failure without the systemctl hint in the text. Start the daemon for your platform (steps 1 and 5), then retry.

tailscale up failed to connect to local tailscaled

tailscale up is a client command, so it fails like all the others while the daemon is down. The fix order matters: daemon first, up second.

tailscale daemon not running ubuntu

On Ubuntu the daemon is the tailscaled systemd unit (step 1), or the tailscale snap on snap installs (step 5). Check is-active before reinstalling anything; a reinstall does not fix a service that was simply never started.

Root cause

Client/daemon split. The socket the CLI dials only exists while tailscaled runs, so a stopped daemon breaks every client command the same way, and the error text points at the daemon because that is the missing piece.

Edge cases

• On headless servers, authenticate with an auth key when you run tailscale up, since there is no browser to complete the login.
• Do not run tailscale up under a short timeout: it blocks waiting for the browser login, and a timeout kill looks like a new failure.
• In containers and LXC guests, no service restart fixes a missing TUN device; the host has to pass /dev/net/tun through.

Tool compatibility

Tailscale on Linux (systemd and snap installs), macOS (app with system extension), and Windows (Tailscale service). Applies whenever the tailscaled daemon is installed but not running.

Related skills

• duplicate node key tailscale: fix the Duplicate node key warning in the admin console: https://vectle.com/skills/skl_qmlicXbtFhGlMME7wMix7w
• tailscale up on a headless server: https://vectle.com/skills/skl_RqENuhopBsY-tKOM-lFSmQ

Provenance

Built from the Tailscale install docs: https://tailscale.com/kb/1032/install-ubuntu

Source: The tailscale command you type is only a client. It talks to the tailscaled daemon over a local socket, and every client command fails with this message when the daemon is not running. This is not a network, account, or install problem. It means the background service is down or was never started.

Verified resolution: Short answer: start the daemon. On Linux: sudo systemctl enable --now tailscaled. Then run sudo tailscale up again. `` failed to connect to local tailscaled; it doesn't appear to be running (sudo systemctl start tailscaled ?) 1. Run sudo systemctl enable --now tailscaled. This starts the daemon now and keeps it enabled across reboots. Expected: no output means success. 2. Confirm with systemctl is-active tailscaled. Expected: active. 3. Retry sudo tailscale status. Expected: your node's info, not the connect error. 4. If the service will not stay up, read journalctl -u tailscaled -n 50. Common causes: a missing /dev/net/tun device (containers and LXC guests need the TUN device passed through from the host) or another VPN holding the device. 5. Other platforms: on macOS relaunch the Tailscale app (the daemon is a system extension, approve it under System Settings, Privacy and Security if blocked). On Windows start the Tailscale service in services.msc. Snap installs: sudo snap restart tailscale. Root cause: client/daemon split. The socket the CLI dials only exists while tailscaled runs, so a stopped daemon breaks every client command the same way. When to use: this exact message on any OS. When NOT to use: if tailscale status works but shows NeedsLogin, that is an expired session, re-authenticate with tailscale up instead. Variant phrasings: "tailscaled doesn't appear to be running", "tailscale up failed to connect to local tailscaled", "tailscale daemon not running ubuntu". Edge cases: on headless servers pass an auth key (tailscale up with your auth key) since there is no browser. Do not run tailscale up` under a short timeout, it blocks waiting for the browser login and a timeout kill looks like a new failure.

Source URL: https://tailscale.com/kb/1032/install-ubuntu

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

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.