Tailscale CLI

Tailscale ships with a built-in CLI that you can use to get information about your Tailscale+WireGuard® network and troubleshoot issues.


Using the CLI

The location of the CLI varies depending on your platform:

Linux

On Linux, the CLI is your primary interface to Tailscale. The tailscale binary is likely already in your $PATH, so commands can be run with:

tailscale <command>
macOS

On macOS, the CLI is bundled inside the Tailscale app. Run commands with:

/Applications/Tailscale.app/Contents/MacOS/Tailscale <command>

If you frequently access the Tailscale CLI, you may find it convenient to add an alias to your .bashrc, .zshrc or shell config to make it easier.

alias tailscale="/Applications/Tailscale.app/Contents/MacOS/Tailscale"
Windows

On Windows, the CLI can be accessed by executing the .exe from the Command Prompt.

tailscale <command>

There is no CLI support for iOS and Android.

Command Reference

up

Up connects your device to Tailscale, and authenticates if needed.

tailscale up [flags]

Running tailscale up without any flags connects to Tailscale.

You can specify flags to configure Tailscale’s behavior. Flags are not persisted between runs; you must specify all flags each time.

To clear previously set flags like tags and routes, pass the flag with an empty argument:

# Connects with `tag:server`
tailscale up --advertise-tags=tag:server

# Connects and clears any tags
tailscale up --advertise-tags=

In Tailscale v1.8 or later, if you forget to specify a flag you added before, the CLI will warn you and provide a copyable command that includes all existing flags.

Available flags:

  • --accept-dns Accept DNS configuration from the admin console. Defaults to accepting DNS settings.
  • --accept-risk=<risk> Accept risk and skip confirmation for risk type. This can be either lose-ssh or all, or an empty string to not accept risk.
  • --accept-routes Accept subnet routes that other nodes advertise. Linux devices default to not accepting routes.
  • --advertise-exit-node Offer to be an exit node for outbound internet traffic from the Tailscale network. Defaults to not offering to be an exit node.
  • --advertise-routes=<ip> Expose physical subnet routes to your entire Tailscale network.
  • --advertise-tags=<tags> Give tagged permissions to this device. You must be listed in "TagOwners" to be able to apply tags.
  • --authkey=<key> Provide an auth key to automatically authenticate the node as your user account.
  • --exit-node=<ip|name> Provide a Tailscale IP or machine name to use as an exit node. To disable the use of an exit node, pass the flag with an empty argument: --exit-node=.
  • --exit-node-allow-lan-access Allow direct access to the local network when routing traffic via an exit node. Defaults to not allowing direct access to your LAN.
  • --force-reauth Force re-authentication.
  • --hostname=<name> Provide a hostname to use for the device instead of the one provided by the OS. Note that this will change the machine name used in MagicDNS.
  • --login-server=<url> Provide the base URL of a control server instead of https://controlplane.tailscale.com. If you are using Headscale for your control server, use your Headscale instance’s URL.
  • --netfilter-mode (Linux only) Advanced feature for controlling the degree of automatic firewall configuration. Values are either “off”, “nodivert”, or “on”. Defaults to “on”, except for Synology which defaults to “off”. Setting this flag to “off” disables all management of netfilter. Setting to “nodivert” creates and manages Tailscale sub-chains, but leaves the calling of those chains up to the administrator. Setting to “on” means using full management of Tailscale’s rules. Note that if you set --netfilter-mode to “off” or “nodivert”, it is your responsibility to configure the firewall securely for Tailscale traffic. We recommend using the rules installed by --netfilter-mode=on as a starting point.
  • --operator=<user> Provide a Unix username other than root to operate tailscaled.
  • --qr Generate a QR code for the web login URL. Defaults to not showing a QR code.
  • --reset Reset unspecified settings to default values.
  • --shields-up Block incoming connections from other devices on your Tailscale network. Useful for personal devices that only make outgoing connections.
  • --snat-subnet-routes (Linux only) Source NAT traffic to local routes that are advertised with --advertise-routes. Defaults to sourcing the NAT traffic to the advertised routes. Set to false to disable subnet route masquerading.
  • --ssh Run a Tailscale SSH server, permitting access per the tailnet admin’s declared access policy, or the default policy if none is defined. Defaults to false.
  • --timeout=<duration> Maximum amount of time to wait for the Tailscale service to initialize. duration can be any value parseable by time.ParseDuration(). Defaults to 0s, which blocks forever.
  • --unattended(Windows only) Run in unattended mode where Tailscale keeps running even after the current user logs out.

down

down disconnects from Tailscale. This command is the same as the “Disconnect” option on the macOS and Windows GUI clients.

tailscale down

When disconnected, you cannot reach devices over Tailscale. To reconnect, re-run tailscale up without any flags.

Available flags:

  • --accept-risk=<risk> Accept risk and skip confirmation for risk type. This can be either lose-ssh or all, or an empty string to not accept risk.

bugreport

The bugreport command is available in Tailscale v1.8 or later. If you don’t see this command, consider updating your Tailscale client.

Bugreport makes it easier to report bugs to the Tailscale team by marking diagnostic logs with indicators to make triage easier.

If you encounter a connectivity issue, run tailscale bugreport on the device experiencing the issue at the time you encounter it. This command will print a random identifier into diagnostic logs, which you can share with our team.

Identifiers look like this:

$ tailscale bugreport
BUG-1b7641a16971a9cd75822c0ed8043fee70ae88cf05c52981dc220eb96a5c49a8-20210427151443Z-fbcd4fd3a4b7ad94

This command shares no personally-identifiable information, and is unused unless you share the bug identifier with our team.

Available flags:

  • --diagnose Prints additional verbose information about the system to the Tailscale logs after generating a bugreport identifier, which can then be viewed by our support team. Defaults to false.
  • --record Pause and then write another bugreport. Use this flag to create an initial bugreport identifier. During the pause, perform the action that reproduces your issue. Then, press Enter to create a second bugreport identifier. Share both bug identifiers with our team. Defaults to false.

cert

Generate certificate and key files on the host for HTTPS certificates in the network.

file

Access and make files available to Taildrop.

Available flags:

  • cp Copy files to a host
  • get Move files out of the Tailscale file inbox

ip

ip returns a device’s Tailscale IP address.

tailscale ip [flags] [<hostname>]

By default, this command returns both an 100.x.y.z IPv4 address and an IPv6 address for the current device. You can return only an IPv4 or IPv6 address by passing either the -4 or -6 flags.

$ tailscale ip -4
100.121.112.23

You can also find the Tailscale IP for other devices on your network by adding the device hostname after the command. For example:

$ tailscale ip raspberrypi
100.126.153.111
fd7a:115c:a1e0:ab12:4843:cd96:627e:9975

Available flags:

  • -4 Only return an IPv4 address
  • -6 Only return an IPv6 address
  • -1 Only return one address, preferring IPv4

lock

Manages tailnet lock for your tailnet.

tailscale lock <sub-command> [sub-flags] <args>

Sub-commands:

  • init Initializes tailnet lock.
  • status Outputs the state of tailnet lock.
  • add Adds one or more trusted signing keys to tailnet lock.
  • remove Removes one or more trusted signing keys from tailnet lock.
  • sign Signs a node key and transmits the signature to the coordination server.
  • disable Consumes a disablement secret to shut down tailnet lock for the tailnet.
  • log Lists changes applied to tailnet lock.
  • local-disable Disables tailnet lock for this node only.

Running tailnet lock with no sub-command and no arguments is equivalent to running tailscale lock status.

Example:

tailscale lock

Example output:

Tailnet lock is ENABLED.

This node is accessible under tailnet lock.

This node's tailnet-lock key: tlpub:1234abcdef

Trusted signing keys:
	tlpub:1234abcdef	(us)
lock init

Initializes tailnet lock for the entire tailnet.

tailscale lock init [flags] <tlpub:trusted-key1, tlpub:trusted-key2, ...>

Available flags:

  • --confirm=false Whether to prompt for confirmation. If true, there is no prompt for confirmation.
  • --gen-disablement-for-support Generate an additional disablement secret and transmit it to Tailscale support. Tailscale support can then use it to disable tailnet lock. We recommend setting this flag. Note that if Tailscale support disables tailnet lock, it will remain disabled and Tailscale support cannot re-enable it, so this would be considered an emergency recovery mechanism, not a temporary disabling of tailnet lock.
  • --gen-disablements <N> Number of disablement secrets to generate. If not specified, defaults to one disablement secret, which is the minimum required to initialize tailnet lock.

The tailnet lock keys specified are those initially trusted to sign nodes or to make further changes to your tailnet lock configuration. These are tailnet lock public keys. You can identify the tailnet lock key for a node you wish to trust by running tailscale lock on that node and then copying the node’s tailnet lock key.

You must specify the tailnet lock key for the node where you are running tailscale lock init as one of the trusted tailnet lock keys.

The disablement secrets are displayed only when you initialize tailnet lock. Make note of them and secure them in a safe place.

Example:

tailscale lock init --gen-disablements=3 --gen-disablement-for-support \
  --confirm tlpub:1234abcdef

Example output:

You are initializing tailnet lock with the following trusted signing keys:
 - tlpub:1234abcdef (25519 key)

3 disablement secrets have been generated and are printed below. Take note of them now, they WILL NOT be shown again.
	disablement-secret:ABC1234
	disablement-secret:DEF5678
	disablement-secret:GHI9012
A disablement secret for Tailscale support has been generated and will be transmitted to Tailscale upon initialization.
Initialization complete.

The disablement secrets are long passwords needed to disable your tailnet lock. See the tailscale lock disable command for more details.

The number of disablement secrets will be the value you specified for --gen-disablements. If you set --gen-disablement-for-support, you’ll see a message about a disablement secret being generated for Tailscale support.

There is currently a bug where initialization may fail with the following error:

error: 500 Internal Server Error: initialization failed: tka init-begin RPC: request returned (400): bootstrap tka state does not trust the initializing node

even when the tailnet lock key for the node you are running on was specified. As a workaround, logout and login again (via tailscale logout and tailscale login) before trying again.

lock status

Outputs the state of tailnet lock. The command shows whether tailnet lock is enabled, the value of the node’s tailnet public key, which nodes are locked out by tailnet lock and cannot connect to other nodes, etc.

tailscale lock status [flags]

Available flags:

  • --json Return a machine-readable JSON response.

Example:

tailscale lock status

Example output:

Tailnet lock is ENABLED.

This node is accessible under tailnet lock.

This node's tailnet-lock key: tlpub:1234abcdef

Trusted signing keys:
	tlpub:1234abcdef	(us)

If the node you run tailscale lock status on doesn’t have an accessible key, the output will look like:

This node is LOCKED OUT by tailnet-lock, and action is required to establish connectivity.
Run the following command on a node with a trusted key:
	tailscale lock sign nodekey:abcdef12 tlpub:11223344

If one of your peer nodes is locked out of your tailnet, after the list of trusted signing keys, the output will look like:

 The following nodes are locked out by tailnet lock and cannot connect to other nodes:
	bob.yak-bebop.ts.net.	100.111.222.33, fd7a:115c:a1e0:aabb:ccdd:eeff:0123:4567	n12345CNTRL
lock add

Adds one or more trusted signing keys to tailnet lock.

This command needs to be run from a node with a trusted tailnet lock key.

tailscale lock add <tlpub:trusted-key1, tlpub:trusted-key2, ...>

The tailnet lock keys specified are tailnet lock public keys. You can identify the tailnet lock key by running tailscale lock on that node and then copying the node’s tailnet lock key.

lock remove

Removes one or more trusted signing keys from tailnet lock.

This command needs to be run from a node with a trusted tailnet lock key.

tailscale lock remove <tlpub:trusted-key1, tlpub:trusted-key2, ...>

The tailnet lock keys specified are tailnet lock public keys. You can identify the tailnet lock key by running tailscale lock on that node and then copying the node’s tailnet lock key.

lock sign

Signs a node key using the tailnet lock key on the current node (the node where the command is running), and transmits the signature to the coordination server.

Signing a node key is necessary to establish connectivity for nodes which are locked out by tailnet lock.

This command needs to be run from a node with a trusted tailnet lock key.

tailscale lock sign <node-key> [<rotation-key>]
lock disable

Consumes the specified disablement secret to disable tailnet lock for the entire tailnet.

tailscale lock disable <disablement-secret>

Disabling tailnet lock is a security-relevant operation—if the disablement procedure lacked authorization checks, a compromised control plane could trivially disable tailnet lock (and all its protections) to attack a tailnet as before. To avoid this, use of a disablement secret is required to globally disable tailnet lock.

Disablement secrets are long passwords generated during the process of enabling tailnet lock, when you ran tailscale lock init. The key derivation function (KDF) derived value of each disablement secret is stored by each node’s tailnet key authority (and hence known by every node in a tailnet), but the secret itself remains confidential until use.

When a disablement secret is used, the secret is distributed to all nodes in the tailnet. Each node can then verify the authenticity of the disablement operation by computing the KDF value of the secret, and comparing it to the stored KDF values in their tailnet key authority (TKA). If they match, then the node can be sure the disablement was authentic, and disable tailnet lock locally.

Once the specified disablement-secret secret is used, it has been distributed to all nodes in the tailnet and should be considered public.

If tailnet lock is re-enabled, new disablement secrets will be generated.

Example:

tailscale lock disable disablement-secret:ABC1234
lock log

List changes applied to tailnet lock.

tailscale lock log [flags]

Available flags:

  • --json Return a machine-readable JSON response.
  • --limit Maximum number of changes to list. Defaults to 50.

Example:

tailscale lock log

Example output:

update 17310b8e655867d3973a72cd20bc7c21f81f7687b4e7911c285f2eb16df5df36 (checkpoint)
Disablement values:
 - 1234abcd
 - 9876aaaa
 - c1d2e3f4
 - 8f6e4d2c
Keys:
  Type: 25519
  KeyID: 1234abcdef
  Votes: 1
lock local-disable

Disables tailnet lock for this node only.

tailscale lock local-disable

This command disables tailnet lock for only the current node (the node where the command is running). If tailnet lock is disabled just for this node, the node will now accept traffic from other nodes that are locked out. It does not mean that the node can send or receive traffic from other nodes in the tailnet that are signed.

If you encounter a significant issue with tailnet lock for your entire tailnet and can’t disable it via tailscale lock disable (for example, if you can’t locate your disablement secret), you could run tailscale lock local-disable on each of your nodes to make your tailnet in effect ignore tailnet lock.

login

Logs this machine in to your Tailscale network. For more information about logging in, see fast-user-switching.

tailscale login [flags]

Available flags:

  • --accept-dns Accept DNS configuration from the admin console. Defaults to accepting DNS settings.
  • --accept-routes Accept subnet routes that other nodes advertise. Linux devices default to not accepting routes.
  • --advertise-exit-node Offer to be an exit node for outbound internet traffic from the Tailscale network. Defaults to not offering to be an exit node.
  • --advertise-routes=<ip> Expose physical subnet routes to your entire Tailscale network.
  • --advertise-tags=<tags> Give tagged permissions to this device. You must be listed in "TagOwners" to be able to apply tags.
  • --authkey=<key> Provide an auth key to automatically authenticate the node as your user account.
  • --exit-node=<ip|name> Provide a Tailscale IP or machine name to use as an exit node. To disable the use of an exit node, pass the flag with an empty argument: --exit-node=.
  • --exit-node-allow-lan-access Allow direct access to the local network when routing traffic via an exit node. Defaults to not allowing direct access to your LAN.
  • --hostname=<name> Provide a hostname to use for the device instead of the one provided by the OS. Note that this will change the machine name used in MagicDNS.
  • --login-server=<url> Provide the base URL of a control server instead of https://controlplane.tailscale.com. If you are using Headscale for your control server, use your Headscale instance’s URL.
  • --nickname=<name> Nickname for the current account.
  • --operator=<user> Provide a Unix username other than root to operate tailscaled.
  • --qr Generate a QR code for the web login URL. Defaults to not showing a QR code.
  • --shields-up Block incoming connections from other devices on your Tailscale network. Useful for personal devices that only make outgoing connections.
  • --ssh Run a Tailscale SSH server, permitting access per the tailnet admin’s declared access policy, or the default policy if none is defined. Defaults to false.
  • --timeout=<duration> Maximum amount of time to wait for the Tailscale service to initialize. duration can be any value parseable by time.ParseDuration(). Defaults to 0s, which blocks forever.
  • --unattended(Windows only) Run in unattended mode where Tailscale keeps running even after the current user logs out.

logout

Log out disconnects from Tailscale and expires the current log in. The next time you run tailscale up, you’ll need to reauthenticate your device.

tailscale logout

If you run tailscale logout on an ephemeral node, the node will be removed from your tailnet immediately.

netcheck

Netcheck provides a report on your current physical network conditions. This command is provided to help debug connection troubles.

tailscale netcheck

Netcheck will output a report like this:

Report:
* UDP: true
* IPv4: yes, <ip-address>
* IPv6: no
* MappingVariesByDestIP: false
* HairPinning: false
* PortMapping: false
* Nearest DERP: 1 (nyc)
* DERP latency:
- 1, nyc = 43.6ms
- 2, sfo = 67.4ms
- 3, sin = 202.5ms
- 4, fra = 91.9ms
- 5, syd = 218.5ms
  • UDP shows whether UDP traffic is enabled on the current network. If this is false, it’s unlikely Tailscale will be able to make point-to-point connections, and will instead rely on our encrypted TCP relays (DERP)
  • IPv4 and IPv6 show your network public IP addresses and support for both protocols.
  • MappingVariesByDestIP describes whether your device is behind a difficult NAT that varies the device’s IP address depending on the destination.
  • HairPinning describes whether your router can route connections from endpoints on your LAN back to your LAN using those endpoints’ globally-mapped IPv4 addresses/ports.
  • PortMapping describes a list of which three port-mapping services exist on your router. Possible values are “UPnP”, “NAT-PMP”, and “PCP”.
  • DERP latency and Nearest DERP describe latency from our encrypted TCP relays (DERP). The lowest latency (“nearest”) server is used for traffic.

If any fields are blank, it means Tailscale wasn’t able to measure that network property.

All the information from tailscale netcheck is also available in the admin console, by clicking on a particular machine.

version

Prints the version of Tailscale.

tailscale version [flags]

Available flags:

  • --daemon Also print local node’s daemon version. Defaults to false.
  • --json Return a machine-readable JSON response.

ping

Ping tries to ping another device exclusively over Tailscale.

The regular ping command often works fine over Tailscale, but tailscale ping provides more details about the connection over Tailscale that can be helpful when troubleshooting connectivity.

tailscale ping <hostname-or-ip>

You can call tailscale ping using either a 100.x.y.z address or a machine name.

Available flags:

  • --c Maximum number of pings to send. Defaults to 10.
  • --icmp, --icmp=false Perform an ICMP-level ping (through WireGuard, but not the local host OS stack). Defaults to false.
  • --peerapi, --peerapi=false Try hitting the peer’s PeerAPI HTTP server. Defaults to false.
  • --tsmp, --tsmp=false Perform a TSMP-level ping (through WireGuard, but not either host’s OS stack). Defaults to false.
  • --timeout=<duration> Maximum amount of time to wait before giving up on a ping. duration can be any value parseable by time.ParseDuration(). Defaults to 5s.
  • --until-direct, --until-direct=false Stop once a direct path is established. Defaults to true.
  • --verbose, --verbose=false Show verbose output. Defaults to false.

serve

Serve content and local server from your Tailscale node to your tailnet.

You can also choose to enable Funnel which allows you to publish a tailscale serve server publicly, open to the entire Internet.

Tailscale Funnel is currently an invite only feature. For more information and to find out how to get an invite, read our blog post Introducing Tailscale Funnel.

serve [flags] <mount-point> {proxy|path|text} <arg>
serve [flags] <sub-command> [sub-flags] <args>

Examples:

  • To proxy requests to a web server at 127.0.0.1:3000:
    $ tailscale serve / proxy 3000
    
  • To serve a single file or a directory of files:
    $ tailscale serve / path /home/alice/blog/index.html
    $ tailscale serve /images/ path /home/alice/blog/images/
    
  • To serve simple static text:
    $ tailscale serve / text "Hello, world!"
    

Default Arguments:

tailscale [flags] serve <mount-point> {proxy|path|text} <arg>

The default serve behavior starts an HTTPS web server on your node, capable of serving content or proxying requests to a local server. Traffic is secured using an automatically provisioned TLS certificate. By default, termination is done by your node’s Tailscale daemon itself.

  • <mount-point> Is a slash-separated path URL path. The root-level mount point would simply be / and, would by matched by making a request to https://my-node.tailnet.ts.net/, for example. For more information how these path patters are matched, refer to the Go ServeMux documentation; our mount points behave similarly.

  • {proxy|path|text} Serve provides three primitives for serving content. proxy allows you to forward requests to a local HTTP web server. path provides the ability to serve files or directories of files and text simply serves a static message.

    • proxy <port-or-ip-port> Accepts a simple port (proxy 3000) which expands to 127.0.0.1:3000. You can also specify the IP itself (proxy 127.0.0.1). Note only 127.0.0.1 is currently supported for proxies.

    • path <full-path> Provide a full, absolute path, to the file or directory of files you wish to serve (path /var/www/html/). If a directory is specified, this will render a simple directory listing with links to files and sub-directories.

    • text "<some-text>" Allows you to provide a simple static message to display (text "Hello, world!").

Available flags:

  • --remove <mount-point> Removes a request handler for the given mount point.
  • --remove tcp <port> Removes a TCP forwarder for a given port.
  • --serve-port <port> Specifies the TCP port serve will listen on. The default port is 443 (HTTPS); however, you can also use 8443 and 10000.

Subcommands

serve [flags] <sub-command> [sub-flags] <args>
  • status [--json] Prints a description of the active servers, their type and mount point as well as how to access them on your tailnet or (if Funnel is on) over the internet.

  • tcp [--terminate-tls] In addition to providing an HTTPS web server, serve offers a raw TCP forwarder, with optional TLS termination.

    Examples

    • To forward packets to a local web server running on 127.0.0.1:8443, run: tailscale serve tcp 8443. Note, traffic is sent with TLS and in this example would need to be handled by your local web server.
    • You can also have your node terminate TLS before forwarding it to your local server. As an example, to serve TLS/SNI traffic from my-node.tailnet.ts.net:10000, and have it terminated then forwarded to 127.0.0.1:5432, do:
      tailscale serve tcp --serve-port=10000 --terminate-tls 5432`)
      
  • funnel {on|off} Funnel allows you to publish a ’tailscale serve’ (HTTPS or TCP) server publicly, open to the entire internet. Turning off Funnel only turns off serving to the internet. Defaults to off. It does not affect serving to your tailnet.

set

Changes specified preferences.

Unlike tailscale up, this command does not require the complete set of desired settings. Only settings explicitly mentioned will be set. There are no default values.

tailscale set [flags]

Available flags:

  • --accept-dns Accept DNS configuration from the admin console.
  • --accept-risk=<risk> Accept risk and skip confirmation for risk type. This can be either lose-ssh or all, or an empty string to not accept risk.
  • --accept-routes, --accept-routes=false Accept subnet routes that other nodes advertise.
  • --advertise-exit-node, --advertise-exit-node=false Offer to be an exit node for internet traffic for the tailnet.
  • --advertise-routes=<ip> Expose physical subnet routes to your entire Tailscale network. This is a comma-separated string, such as “10.0.0.0/8,192.168.0.0/24”), or an empty string to not advertise routes.
  • --exit-node <ip|name> A Tailscale IP or machine name to use as an exit node, or an empty string to not use an exit node.
  • --exit-node-allow-lan-access, --exit-node-allow-lan-access=false Allow direct access to the local network when routing traffic via an exit node.
  • --hostname=<name> Hostname to use for the device instead of the one provided by the OS. Note that this will change the machine name used in MagicDNS.
  • --nickname=<name> Nickname for the current account.
  • --operator=<user> A Unix username other than root to operate tailscaled.
  • --shields-up, --shields-up=false Block incoming connections from other devices on your Tailscale network. Useful for personal devices that only make outgoing connections.
  • --ssh, --ssh=false Run a Tailscale SSH server, permitting access per the tailnet admin’s declared access policy, or the default policy if none is defined.

ssh

Establishes a Tailscale SSH session to a Tailscale machine.

You can often use the regular ssh command or another SSH client to make an SSH session to a Tailscale machine. However, when your local node is in userspace-networking mode and can’t make a direct connection, use tailscale ssh. This sets up an SSH ProxyCommand to connect via the local tailscaled daemon. You can also use tailscale ssh when your local node is in kernel mode.

The tailscale ssh command automatically checks the destination server’s SSH host key against the node’s SSH host key as advertised via the Tailscale coordination server.

tailscale ssh <args>

<args> is one of the following forms:

  • host The destination server. An interactive session will prompt you for the user name to use for the session.
  • user@host The user name for the session and the destination server.

For both forms, host can be the destination server’s MagicDNS name (even if --accept-dns=false was set on the local node) or the destination server’s Tailscale IP address.

tailscale ssh is not available on sandboxed macOS builds—use the regular ssh client instead.

status

Status shows the status of your connections to other Tailscale devices.

tailscale status

This command returns a table of information like so:

1           2         3           4         5
100.1.2.3   device-a  apenwarr@   linux     active; direct <ip-port>, tx 1116 rx 1124
100.4.5.6   device-b  crawshaw@   macOS     active; relay <relay-server>, tx 1351 rx 4262
100.7.8.9   device-c  danderson@  windows   idle; tx 1214 rx 50
100.0.1.2   device-d  ross@       iOS       —

From left-to-right, these columns represent:

  • Column 1 is a Tailscale IP, which you can use to connect to the device.
  • Column 2 is the machine name of the device. If you use MagicDNS, you can also use this name to connect.
  • Column 3 is the email address for the owner of the device.
  • Column 4 is the device OS.
  • Column 5 shows the current connection status.

Connection status (column 5) is shown using three terms:

  • active means traffic is currently being sent/received from this device. You’ll also see either (a) “direct” for peer-to-peer connections, along with the IP address used to connect or (b) “relay” for connections using a relay server along with a city code (nyc, fra, tok, syd) for the respective location.
  • idle means traffic is not currently being sent/received from this device.
  • means no traffic has ever been sent/received from this device.

active and idle connection statuses will also include tx/rx values indicating the number of bytes sent (tx) and received (rx) from this device.

You can filter this list down to only active connections by running tailscale status --active.

Running tailscale status with the --json flag will return a machine-readable JSON response.

tailscale status --json

Combine this with jq to automate data collection about your network. For example, the following command will count and sort which relay servers your Tailscale peers are connected to.

tailscale status --json | jq -r '.Peer[].Relay | select(.!="")' | sort | uniq -c | sort -nr

switch

Switches to a different Tailscale account. For more information about switching accounts, see fast-user-switching.

tailscale switch <account> [flags]

Examples:

  • To switch to the alice@example.com account:

    tailscale switch alice@example.com
    
  • To switch to the account that has the nickname “work”:

    tailscale switch work
    

Available flags:

  • --list Lists available accounts.

update (alpha)

The update command is available in Tailscale v1.36 or later for Windows and Ubuntu/Debian Linux. If you don’t see this command and you are running Windows or Ubuntu/Debian Linux, consider updating your Tailscale client.

Update the Tailscale client version to the latest version, or to a different version.

tailscale update [flags]

Available flags:

  • --dry-run Show what update would do, without performing the update and without prompting to start the update.
  • --track The track to check for updates, either “stable” or “unstable”. If not specified, the update uses the track currently in effect for the client.
  • --version An explicit version to use for the update or downgrade. You cannot specify both --track and --version.
  • --yes Perform the update without interactive prompts. Defaults to false.

If you downgrade to a version that does not have the tailscale update functionality, you won’t be able to run tailscale update to return to the prior version. You would need to perform an update without using the Tailscale CLI.

To determine the current version on a client, run tailscale version.

Examples:

Update to the latest version within your current track (stable or unstable, depending on what you’re running):

tailscale update

Update to the latest version within your current track without using interactive prompts:

tailscale update --yes

Update to Tailscale v1.34:

tailscale update --version=1.34.0

Update to the latest unstable version:

tailscale update --track=unstable

web

Spins up a webserver for controlling the tailscaled daemon, where the CLI or a native app is not practical, e.g., on NAS devices.

Last updated

WireGuard is a registered
trademark of Jason A. Donenfeld.

© 2023 Tailscale Inc.

Privacy & Terms