Use MagicDNS and test the path

MagicDNS registers a private name for each tailnet device. New tailnets normally have it enabled by default.

A short hostname such as lab-server is easier to use than its Tailscale IP. The full name includes your tailnet domain, something like lab-server.tail4a5b6.ts.net, but inside the tailnet the short form resolves too.

Test the name

Start with a plain connection test:

ssh ubuntu@lab-server

If SSH connects, the name resolved to the Tailscale address and the private path works. Names beat raw addresses in every config file you will write from now on: they survive device replacement, and they make policies and logs readable.

Test the path, not just reachability

Test the name, then use tailscale ping to see whether the path is direct or relayed. Ordinary ping tests IP reachability but does not explain Tailscale path negotiation.

tailscale ping lab-server

pong from lab-server (100.101.9.23) via 203.0.113.40:41641 in 14ms

via <ip>:<port> means a direct connection. If you see via DERP(fra) instead, traffic is relayed through Tailscale’s Frankfurt relay: still encrypted, still working, just not direct. The first ping sometimes goes through DERP while the direct path is negotiated. Run it again and watch it switch.

Prove the old path was not used

Connect by name, record whether Tailscale reports a direct or DERP path, and confirm the server’s public SSH address was not used:

ssh ubuntu@lab-server 'echo $SSH_CONNECTION'

100.87.12.44 52441 100.101.9.23 22

Both addresses are tailnet addresses. The connection entered through the Tailscale interface, not the public one.

If name resolution fails, check that MagicDNS is enabled in the admin console DNS page and that the client accepts DNS settings. When tailscale ping works by IP while the name fails, the problem is DNS, not connectivity. That distinction saves you from debugging the wrong layer.