Tailscale subnet router vs exit node: decide by destination

Which route fits your destination?

Start with what you need to reach, then check the corresponding setup. These are routing roles from Tailscale's documentation, not measurements of your network. More than one role can be needed for different destinations. [1][2]

Download the destination-planning worksheet (CSV) — Write one destination per row and keep unverified access pending.

Download the six-case routing exercise (Node.js) — Run node tailscale-destination-exercise.mjs with Node.js 22 or later. It classifies fictional inputs without connecting to or changing a network.

Write the destination before changing routing

A remote-access request often hides two different jobs: reaching a printer at home and sending ordinary web traffic through a home connection. Put each destination in its own worksheet row. Record who owns it, which client needs access, and the smallest useful test. This guide is a planning procedure based on documentation, not a tested network configuration. Only change networks and devices you are authorized to administer.

Tailscale describes direct client installation as preferable where feasible. A subnet router extends access to devices that cannot run that client; an exit node handles outbound internet routing. These roles can coexist, but one does not automatically establish the other. [1][2]

Choose one role for the first test

For a computer that supports Tailscale, investigate installing the client directly before adding a gateway. For an appliance that cannot run it, record the private address or subnet that must be reachable through a subnet router. For public internet routing, identify the proposed exit node and the client that will select it. Keep unrelated destinations out of the initial test.

The subnet setup documentation separates advertising routes, approving them, access rules, and client use. The exit-node documentation likewise separates advertising, approval, permission, and client selection. Treat those as separate checks; a visible device in an administration console is insufficient evidence that your application works. [1][2]

Prepare a bounded change record

Write down the existing working connection, the proposed gateway, operating system, installed client version, and the exact vendor instructions for that platform. Record a local recovery contact or access path before making a remote change that could disconnect you. Use the worksheet for status and ownership, never passwords or reusable authentication material.

Ask the administrator to review the intended destination and access scope. Avoid widening access just because the first attempt fails. Check whether the target application itself is listening and whether its own login works. A routing failure, an application failure, and a rejected application login need different fixes.

Worked example: a fictional home printer

In this simulated example, Jo needs to reach an owned printer from a laptop while away. The printer cannot run Tailscale; the laptop can. Jo selects a subnet-router investigation and leaves the exit-node column unnecessary. The worksheet records printer access as pending until an authorized print test succeeds from the outside connection.

A second request appears: use a home connection for a permitted web-service test. Jo adds a separate exit-node row. Even if the printer test passes, that row remains pending. This prevents a single green status from hiding two distinct requirements. No latency, print success, or service compatibility in this example is measured.

Original exercise: change one destination or setting

We ran tailscale-destination-exercise.mjs locally on September 20, 2026. The six cases below are an original planning exercise, not a VPN experiment. The program classifies labels supplied in its fixtures; it never discovers routes, calls Tailscale, changes settings, or sends network traffic. Every listed path is a modeled role, not an observed successful connection.

The controlled comparison changes the destination from a private printer to a public website while leaving subnet readiness true: the role changes from subnet router to ordinary internet. Selecting an exit node changes the public-website role, but it does not replace the printer's subnet-planning requirement. Tailscale documents that exit nodes capture traffic not already directed to a subnet router or app connector. [2]

Download the exercise from the resource library and run node tailscale-destination-exercise.mjs with Node.js 22 or later. No packages are required. Change subnetReady or exitSelected in one case and rerun. The output teaches which verification track belongs to each request; it cannot establish route approval, client route acceptance, application access, latency, or permission.

What the destination labels deliberately leave out

The private-subnet label means a remote subnet you intend to reach through an approved subnet router. It does not mean every private IP address should take that path. The client's local LAN is a separate case: Tailscale provides an Allow Local Network Access setting when using an exit node. This exercise does not model that setting, overlapping networks, DNS, app connectors, or platform-specific routing. [2]

The subnetReady fixture is an asserted planning input, not evidence that advertising, approval, access policy, client use, and the target service all work. Use the existing worksheet to record those checks independently. A pending classifier result tells you which setup is missing from the model; a named path still needs an authorized end-to-end test.

What a connectivity check can show on your network

We have not yet recorded a tailscale netcheck run for this guide; run the command on your own network and compare the UDP, IPv6, MappingVariesByDestIP and PortMapping fields with Tailscale's documentation. A netcheck run tests one device on one network. It does not test a subnet router or an exit node; it shows the network conditions those features depend on.

Tailscale's documentation says that when UDP is false, point-to-point connections are unlikely and traffic relies on its encrypted relays, and that a blank field means the property could not be measured.

Run the same check on the network where the router or exit node will live, and again on the network you will connect from, such as a hotel. If one side reports UDP: false or MappingVariesByDestIP: true, expect relayed traffic and plan for higher latency before blaming the route choice.

• Record UDP, MappingVariesByDestIP, PortMapping and the nearest relay latency on both networks.
• Remove public IP addresses before sharing the output.
• Treat the result as a property of that network on that day, not of the device.

Verify the result and the failure path

Test from the actual intended client connection, using the exact target application. Record the time, destination, expected result, and observed result. For exit-node routing, Tailscale documents checking the resulting public IP address; this is evidence about internet egress, not proof that every private-network service is reachable. Local-network access also has its own exit-node setting. [2]

Finally, document how to stop using the added route and recover the previous connection. Repeat a representative task after reconnecting the client. If any permission, route approval, or target behavior remains unresolved, keep the decision pending. This worksheet cannot establish employer permission, network security completeness, uptime, or a product's suitability for your particular hardware.

Sources & verification

Product details and prices can change. Check the linked provider before buying.

1. Tailscale: Subnet routers; validated January 12, 2026 Accessed 23 Sep 2026
2. Tailscale: Exit nodes; validated December 15, 2025 Accessed 23 Sep 2026
3. Tailscale CLI: tailscale netcheck Accessed 2 Oct 2026
4. Tailscale: Subnet routers, Disable SNAT note; validated September 29, 2026 Accessed 13 Oct 2026