MagicRoute Beta Picks the Nearest Healthy Connector for Each Client

MagicRoute ranks connectors from each client's point of view #

MagicRoute scores and ranks every connector in a tailnet from the client's side, according to the MagicRoute beta announcement. Each client is matched to its top choice for each subnet route and app, and when two connectors tie for first place, clients are spread fairly between them. The source's example uses a client with two healthy top choices, which gives it an even chance of picking either one.

This matters if you run overlapping subnet routers, advertising the same routes from several machines for redundancy, capacity or proximity. The announcement says the score is based on coarse location today, and that approximate distances are compared because they do not change unless the client moves, unlike latency measurements. This suggests that the ranking will be steadier than a latency-based ranking, though the source does not make that comparison directly.

Why DERP regions were replaced for connector selection #

The earlier approach, regional routing, grouped connectors by their home DERP servers. The announcement reports that a connector on a fast backbone could have latency to several DERP regions within a couple of milliseconds of each other, so small jitter made it flap between regions. Each flap made the connector's clients switch too, and the source says the effect was dropped SSH sessions and interrupted large file transfers.

"When a connector flaps, every client on it breaks existing connections"

MagicRoute beta announcement

The source also says that custom DERP servers were excluded from regional routing because their regions were incompatible with Tailscale's public regions. MagicRoute does not rely on DERP regions, so the announcement says it also works in tailnets with custom DERP servers. If you host your own DERP servers, this is the change that affects you directly.

MagicRoute failover keeps sessions on healthy connectors #

Clients keep using their preferred connector while it is healthy. When it goes offline, the client works down its ranked list until it finds a healthy connector. In the source's example, both top choices of one client are unhealthy, so it fails over to its next best choice. The announcement presents this as a way to avoid breaking connections unnecessarily.

For administrators, this means health and ranking determine failover order, and you cannot override a single connector's position. The source states that MagicRoute is one option for the whole tailnet with no per-connector opt-outs, because rules for individual nodes may lead to unexpected interactions and bad behavior.

Route selection options in the admin console #

MagicRoute replaces the single regional routing switch with a Configure section at Settings > General > Route Selection > Configure. On Premium and Enterprise plans, the MagicRoute beta announcement lists four options:

• Active-passive failover: one primary connector serves the tailnet, and others stand by until it goes offline.
• Regional routing: clients use connectors in the same DERP region.
• Regional routing with in-region failover: one primary connector per DERP region, with others on standby. The source notes this option is not available without contacting support.
• MagicRoute: each client selects the nearest healthy machine and keeps active sessions steady.

Review which option your tailnet uses before the change, because the setting covers the whole tailnet. The announcement links to its docs page for the details of each option.

MagicRoute client versions and plan requirements #

MagicRoute is in beta for Premium and Enterprise customers. According to the announcement, all client versions support MagicRoute for subnet routers, app connectors and Tailscale Service hosts. Clients from version 1.86.0 onward also support MagicRoute when suggesting recommended exit nodes.

If you rely on exit node suggestions, check that your clients are at version 1.86.0 or later. The source does not state when the beta ends or when it becomes generally available, so plan changes against the beta status it describes.

MagicRoute reachability checks and feedback #

The announcement says Tailscale is looking into reachability checks, in which clients test whether they can actually reach a connector, and is considering additional signals for connector scoring. Neither is described as available in this beta. Tailscale asks beta users to report results through a Feedback ticket, and the announcement invites you to try MagicRoute and report how it works for your tailnet.