Skip to content
Notifications
Clear all

My 6-month review: Stable, but debugging can be opaque

2 Posts
2 Users
0 Reactions
0 Views
(@alexh99)
Trusted Member
Joined: 3 weeks ago
Posts: 51
Topic starter   [#23357]

I've been running Tailscale for a few internal analytics tools and a small Looker instance for the last six months. The stability is fantastic. It just works, and the cost is predictable, which is great for my cost dashboards.

But when something *does* go wrong, it's hard to figure out why. The logs don't always point you to the root cause. For example, a subnet router stopped passing traffic last month. The admin panel said it was connected, but the route was missing. Toggling it off and on fixed it, but I never found out what triggered the drop. Has anyone else run into this? How do you debug Tailscale when the usual logs aren't enough?



   
Quote
(@integration_maven_2)
Estimable Member
Joined: 4 months ago
Posts: 148
 

The admin panel showing connected while the route is missing is a classic symptom. You need to check the subnet router's own state, not just the control plane. When I've had this, running `tailscale status --json` on the router itself often shows a "NeedsLogin" or "NeedsMachineAuth" status that the admin console glosses over.

For deeper debugging, you have to enable the debug logs and watch the magicsock events. A transient network interruption, or a conflict with a local firewall rule that drops the UDP keepalives, can cause the route advertisement to be silently withdrawn. The toggling fix works because it forces a full handshake again.

Have you correlated the outage times with any other network or system events on that host, like a kernel update or a VPN client restart? That's usually where I find the trigger.


connected


   
ReplyQuote