{"slug":"tailscaled-daemon","title":"tailscaled daemon","tags":["tailscale"],"agent_summary":"Last validated: Jan 5, 2026","trigger_phrases":[],"runnable":false,"markdown":"\r\n# tailscaled daemon\r\n\r\nLast validated: Jan 5, 2026\r\n\r\nThe Tailscale software that runs on your devices is split across\r\nseveral binaries and processes.\r\n\r\n## [Platform differences](https://tailscale.com/docs/reference/tailscaled\\#platform-differences)\r\n\r\nOn most platforms, the [CLI](https://tailscale.com/docs/reference/tailscale-cli) is a binary named\r\n`tailscale` (or `tailscale.exe`) and the more privileged daemon that\r\ndoes all the network handling is called `tailscaled` (or\r\n`tailscaled.exe`). Note the final `d` for \"daemon\". The majority of the\r\nCLI commands accessible by using the `tailscale` command require that the daemon\r\nbe running on the machine.\r\n\r\nThere are [three ways to run Tailscale on macOS](https://tailscale.com/docs/concepts/macos-variants).\r\nOnly the third non-GUI way contains the typical `tailscale` vs\r\n`tailscaled` split. The two GUI variants bundle all components into\r\none binary that macOS loads in different contexts: the GUI, the daemon\r\n(named either `IPNExtension` for the App Store variant or\r\n`io.tailscale.ipn.macsys.network-extension` for the zip file\r\ndownload), and the CLI (which is the same binary as the GUI, but goes\r\ninto CLI mode when run from a terminal). The daemons for the two macOS\r\nGUI variants, despite having different names, are virtually\r\nidentical. But they're not technically `tailscaled`, the subject of this topic, despite sharing the majority of the same code. Notably,\r\nany `tailscaled` behavior that involves changing flags to `tailscaled`\r\nis not always available on the macOS GUI variants.\r\n\r\n## [Where does tailscaled run?](https://tailscale.com/docs/reference/tailscaled\\#where-does-tailscaled-run)\r\n\r\nOn Linux and other Unix-like platforms, `tailscaled` typically runs as a\r\nsystemd service, or whatever your distro or OS's init system is.\r\n\r\nOn macOS, `tailscaled` (when not using a GUI build, as mentioned\r\nabove) runs as a `launchd` service.\r\n\r\nOn Windows, `tailscaled` runs as a Windows service named \"Tailscale\".\r\n\r\n## [Stopping and starting tailscaled](https://tailscale.com/docs/reference/tailscaled\\#stopping-and-starting-tailscaled)\r\n\r\nYou should not normally need to manually stop and start the\r\n`tailscaled` process. It should go into an idle state when you use the\r\nCLI command `tailscale down`. If you're debugging something or\r\nchanging flags, though, the instructions vary by platform.\r\n\r\nOn systemd, you can run `sudo systemctl $VERB tailscaled`, where the verb is one of `stop`, `start`, `restart`, or the like.\r\n\r\nOn Windows, you can run `net stop Tailscale` or `net start Tailscale`,\r\nor use the Windows Service Manager.\r\n\r\n## [Getting logs from tailscaled](https://tailscale.com/docs/reference/tailscaled\\#getting-logs-from-tailscaled)\r\n\r\nA portable way to attach to the daemon and stream its logs is to use\r\nthe CLI and run `tailscale debug daemon-logs`. That does not currently support\r\ngetting any retroactive logs, however.\r\n\r\nOn systemd, you can use `journalctl -u tailscaled --since=\"1 hour ago\"`.\r\n\r\nOn Windows, refer to `C:\\ProgramData\\Tailscale\\Logs`.\r\n\r\nOn macOS, for the GUI builds, use `Console.app` and search for\r\n`Tailscale` or `IPNExtension`.\r\n\r\n## [Flags to tailscaled](https://tailscale.com/docs/reference/tailscaled\\#flags-to-tailscaled)\r\n\r\n`tailscaled` has a number of flags (command-line arguments) that do\r\nvarious things. Some are not stable interfaces and meant primarily for\r\ndebugging. Some of the more frequently used and stable ones are:\r\n\r\n- `--tun=NAME` to specify the TUN device name, or `userspace-networking` as a magic value to not use kernel support and do everything in-process.\r\n- `--port=N` to set the UDP port to listen on for peer-to-peer traffic; 0 means to auto-select.\r\n- `--verbose=N`, where N defaults to 0. Values 1 or higher are increasingly verbose.\r\n- `--debug=localhost:8080`, to run a debug HTTP server serving paths such as `/debug/pprof`, `/debug/metrics`, `/debug/ipn`, or `/debug/magicsock`. The exact details of what's accessible over the debug server is subject to change over time.\r\n- `--no-logs-no-support` disables telemetry and opts you out of getting any support that would then require such telemetry for debugging\r\n\r\nTo control where and how state (including preferences and keys) is stored, use:\r\n\r\n- `--statedir=` for a directory on disk where to store config, keys,\r\nTaildrop files, and other state.\r\n- `--state=` to either a `/path/to/file`, `kube:` to use\r\nKubernetes secrets, `arn:aws:ssm:...` to store state in AWS SSM, or\r\n`mem:` to not store state and register as an ephemeral node. By default, if not\r\nprovided, the state is stored in `/tailscaled.state`.\r\n- `--encrypt-state` to optionally encrypt the state file using the local TPM\r\ndevice on Linux.\r\n\r\nThere are also two flags to run proxies:\r\n\r\n- `--socks5-server=[host]:port`, to run a SOCK5 server, making your tailnet accessible by using SOCKS5\r\n- `--outbound-http-proxy-listen=[host]:port`, to run an HTTP proxy server, making your tailnet accessible by using HTTP.\r\n\r\nThe SOCK5 and HTTP proxy may have the same value in which case only\r\none port is opened but will automatically vary which protocol it\r\nspeaks based on what the client says first.\r\n\r\nThe following flags take an action and exit:\r\n\r\n- `--version` prints version info and exists\r\n- `--cleanup` cleans up system state from a previous run\r\n\r\n## [Setting flags](https://tailscale.com/docs/reference/tailscaled\\#setting-flags)\r\n\r\nSetting `tailscaled` flags varies by platform.\r\n\r\nOn Linux, you can modify the `FLAGS` in `/etc/default/tailscaled`,\r\nwhich the systemd unit definition will include.\r\n\r\n## [Environment variables](https://tailscale.com/docs/reference/tailscaled\\#environment-variables)\r\n\r\n### [Windows](https://tailscale.com/docs/reference/tailscaled\\#windows)\r\n\r\nYou can set some environment variables on Windows by doing the following:\r\n\r\n- Create a `tailscaled-env.txt` file in `C:\\ProgramData\\Tailscale`.\r\n- In the `tailscaled-env.txt` file you can set `PORT=N` (for example, to change the default UDP listen port).\r\n- Save the file and run `net stop Tailscale`, `net start Tailscale` to apply the changes.\r\n","html":"

tailscaled daemon

\n

Last validated: Jan 5, 2026

\n

The Tailscale software that runs on your devices is split across\r\nseveral binaries and processes.

\n

Platform differences

\n

On most platforms, the CLI is a binary named\r\ntailscale (or tailscale.exe) and the more privileged daemon that\r\ndoes all the network handling is called tailscaled (or\r\ntailscaled.exe). Note the final d for \"daemon\". The majority of the\r\nCLI commands accessible by using the tailscale command require that the daemon\r\nbe running on the machine.

\n

There are three ways to run Tailscale on macOS.\r\nOnly the third non-GUI way contains the typical tailscale vs\r\ntailscaled split. The two GUI variants bundle all components into\r\none binary that macOS loads in different contexts: the GUI, the daemon\r\n(named either IPNExtension for the App Store variant or\r\nio.tailscale.ipn.macsys.network-extension for the zip file\r\ndownload), and the CLI (which is the same binary as the GUI, but goes\r\ninto CLI mode when run from a terminal). The daemons for the two macOS\r\nGUI variants, despite having different names, are virtually\r\nidentical. But they're not technically tailscaled, the subject of this topic, despite sharing the majority of the same code. Notably,\r\nany tailscaled behavior that involves changing flags to tailscaled\r\nis not always available on the macOS GUI variants.

\n

Where does tailscaled run?

\n

On Linux and other Unix-like platforms, tailscaled typically runs as a\r\nsystemd service, or whatever your distro or OS's init system is.

\n

On macOS, tailscaled (when not using a GUI build, as mentioned\r\nabove) runs as a launchd service.

\n

On Windows, tailscaled runs as a Windows service named \"Tailscale\".

\n

Stopping and starting tailscaled

\n

You should not normally need to manually stop and start the\r\ntailscaled process. It should go into an idle state when you use the\r\nCLI command tailscale down. If you're debugging something or\r\nchanging flags, though, the instructions vary by platform.

\n

On systemd, you can run sudo systemctl $VERB tailscaled, where the verb is one of stop, start, restart, or the like.

\n

On Windows, you can run net stop Tailscale or net start Tailscale,\r\nor use the Windows Service Manager.

\n

Getting logs from tailscaled

\n

A portable way to attach to the daemon and stream its logs is to use\r\nthe CLI and run tailscale debug daemon-logs. That does not currently support\r\ngetting any retroactive logs, however.

\n

On systemd, you can use journalctl -u tailscaled --since=\"1 hour ago\".

\n

On Windows, refer to C:\\ProgramData\\Tailscale\\Logs.

\n

On macOS, for the GUI builds, use Console.app and search for\r\nTailscale or IPNExtension.

\n

Flags to tailscaled

\n

tailscaled has a number of flags (command-line arguments) that do\r\nvarious things. Some are not stable interfaces and meant primarily for\r\ndebugging. Some of the more frequently used and stable ones are:

\n\n

To control where and how state (including preferences and keys) is stored, use:

\n\n

There are also two flags to run proxies:

\n\n

The SOCK5 and HTTP proxy may have the same value in which case only\r\none port is opened but will automatically vary which protocol it\r\nspeaks based on what the client says first.

\n

The following flags take an action and exit:

\n\n

Setting flags

\n

Setting tailscaled flags varies by platform.

\n

On Linux, you can modify the FLAGS in /etc/default/tailscaled,\r\nwhich the systemd unit definition will include.

\n

Environment variables

\n

Windows

\n

You can set some environment variables on Windows by doing the following:

\n\n"}