One Tailscale Host Unreachable: Subnet Router or Exit Node?

One Tailscale host answers while another stays dark, or everything works until public websites start reporting the wrong country. Both complaints arrive as "Tailscale is broken", and both are usually the wrong construct enabled for the wrong destination. A subnet router exposes a private network to the tailnet, while an exit node changes where internet traffic leaves. Sort the failing destination first, then pick the role that covers it.

Start from the destination that failed

Write down the address or name that did not work, and what kind of thing it is. A device on a private LAN behind another site, a service on your own segment, and a public website are three routing problems that happen to share one client. The distinction is not cosmetic, because the two constructs cover different sets of destinations. Enabling one does nothing for the other, and that is the whole source of the confusion.

Note the address family as well. A subnet advertised only as IPv4 leaves IPv6 destinations on the local path, which reads as a partial failure until someone compares both routing tables. Record what you expected the path to be, so the test later has something to contradict.

Reach a device that never runs Tailscale

The router announces specific ranges to the tailnet, then relays packets between the tailnet and the private segment, so the devices on that segment need no client of their own. Reaching a NAS at the office from a laptop at home is exactly this case. The router is the only member of the tailnet on that side.

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

Advertising is only the first of three conditions. The route has to be approved for the tailnet, the client has to accept advertised routes, and an access rule has to permit the connection. That chain is why the symptom is so often that the router is up and the NAS is not. A reachable router proves the tunnel works; it proves nothing about approval, client acceptance or policy.

Each of those three failures looks different in the admin console. Check them in order rather than changing all three at once, because a second change hides which one mattered.

Send public traffic out through another machine

An exit node routes your general internet traffic through itself, which is the closest analogue to the full-tunnel arrangement in other VPN products. It needs three separate consents too: the device advertises the role, an administrator permits it, and the client selects it. Joining a tailnet sends nothing through another member by default.

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

Selecting an exit node does not automatically grant access to that node's own LAN. The LAN-access option exists precisely because those are different permissions, and leaving it off is the safer default. Routes to other Tailscale resources keep their own handling even while an exit node is active. That is why a subnet-hosted service can keep working while the public internet path has changed.

An exit node also changes how the internet sees you, not only how fast it feels. Expect geolocation, streaming catalogues and rate limits to follow the exit's address rather than yours.

Read the three-way split when only one host fails

A printer on your own segment, a NAS behind a remote subnet router, and a public site are three destinations with three different paths. If exactly one of them fails, the defect belongs to that destination's path rather than to the client as a whole. For the local printer while an exit node is in use, the LAN-access setting is the usual answer. For the remote NAS, check the advertised range, its approval state and the access rules in that order. For a public site, check which exit node is selected and whether the client actually accepted it.

If the address works and the name does not, stop looking at routes. Private DNS is configured separately, and a name that resolves to the wrong address fails in a way that looks identical to a blocked route. Test the address first, then the name, and the two results tell you which layer to open.

Confirm the path you think you built

Verification is a route lookup plus an address check, not a ping. The lookup tells you which interface a destination would use, and the address check tells you which range the destination actually lives in. A ping that succeeds says the host is alive somewhere, which is not the question. Run both before you change any configuration.

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

Pair that with the tailnet's own view, which shows whether the peer is directly connected or relayed. A relayed path still works, and it explains latency complaints that have nothing to do with the route you were debugging. The subnet router documentation covers the approval step if it is unfamiliar. Then write down which construct covers which destination for your own network, because the next person to add a site will ask the same question.