After logging in to Tailscale, the tray icon is always stuck on Starting.

It's like a receptionist who keeps saying "opening soon", but there's actually no one behind the door who can open the safe. At first, I thought it was a problem with the network, login callback, or virtual network card, but in the end, I found out: the real culprit was Tailscale's local status file and an old key that was no longer recognized by the TPM.

Check the service first, no need to rush to reinstall

First, use PowerShell to check the service and process:

Get-Service -Name Tailscale
Get-Process | Where-Object { $_.ProcessName -like '*tailscale*' }

At that time, the service status was Running, and the desktop frontend was also running. In the process list, two tailscaled.exe could still be seen, which looked like the background was repeatedly started at first glance.

After further checking, it was confirmed that one of them was a Windows service process, and the other had a /subproc parameter, which was a normal subprocess started by it, and it was not two backgrounds competing for control.

Looking at the network configuration again, the Tailscale virtual network card already existed. This indicates that the installation and driver were not completely malfunctioning, and the problem was more like the desktop frontend and background status were out of sync.

Ordinary terminal only saw "access denied"

Execute:

tailscale status
tailscale version

The version can be displayed normally, but when querying the status, it prompts that it cannot access the local tailscaled. This is a phenomenon that can easily lead to misdirection: an ordinary permission terminal may not have permission to access the local pipe used by the background service, which does not mean that the service itself has crashed.

So I used the administrator PowerShell to check and restarted the service once:

Restart-Service -Name Tailscale
Start-Sleep -Seconds 3
tailscale status

This time, the background finally stopped just saying "Starting" and instead revealed the real issue:

State store failed to initialize
failed to unseal state file
failed to unseal encryption key with TPM
TPM_RC_INTEGRITY: integrity check failed
unexpected state: NoState

It turns out that TPM "doesn't recognize the old key"

Tailscale's device state is stored locally, and some versions use TPM to seal encryption keys. If you upgrade your BIOS, replace your motherboard or TPM, migrate your system disk, or restore a virtual machine snapshot too quickly, the internal state of the TPM may change.

The state file is still there, and the key seems to be there too, but the TPM will say coldly: "This key was not issued by me." As a result, Tailscale cannot decrypt the original device identity, and the backend enters NoState, while the desktop frontend can only get stuck on Starting.

Windows: Re-login after backing up the state file

Uninstalling and reinstalling directly may not work, because the damaged state file may still be left in ProgramData. Compared to deleting the entire directory, a more stable approach is to rename and back up the state file first.

In the administrator PowerShell, execute:

Stop-Process -Name 'tailscale-ipn' -Force -ErrorAction SilentlyContinue
Stop-Service -Name Tailscale -Force

Rename-Item `
  -LiteralPath 'C:\ProgramData\Tailscale\server-state.conf' `
  -NewName 'server-state.conf.tpm-broken.bak'

Start-Service -Name Tailscale
Start-Process 'C:\Program Files\Tailscale\tailscale-ipn.exe'

Then check:

tailscale status

If the output becomes:

Logged out.

Indicates that the background has recovered from "unable to open the old safe" to a clean and initializable state. At this time, you can re-login from the tray icon.

Note: This will generate a new Tailscale device identity. After confirming that the new device is connected normally, you can delete the old offline device in the Tailscale management background. The backup file contains device status information and should be kept properly; delete it only when you confirm that you no longer need to restore.

Linux: Back up first, don't delete directly

On Linux, if you encounter the same TPM unlock error, you can also stop the service and back up the status directory first:

sudo systemctl stop tailscaled
sudo mv /var/lib/tailscale /var/lib/tailscale.tpm-broken.bak
sudo systemctl start tailscaled

Then log in again:

sudo tailscale up

Confirm that everything is running normally before deciding whether to clean up the backup directory.

Final Review

The most confusing aspect of this failure was the simultaneous presence of three phenomena: the service showed as Running, the virtual network card had been created, but the desktop client was stuck on Starting.

The truly effective troubleshooting sequence is:

  1. Confirm that the Windows service and frontend process exist;
  2. Distinguish between normal child processes and abnormal duplicate processes;
  3. Run tailscale status in an administrator terminal to bypass local pipe permission interference;
  4. Use the health check to find TPM_RC_INTEGRITY;
  5. Back up the undecryptable state files and let Tailscale regenerate the device identity.

So, next time you see Tailscale saying "starting" all the time, you might want to ask in the background: is it that the network is not connected, or has the TPM suddenly lost its memory?