What changed
Tailscale's October 19, 2026 blog announced MagicRoute, a beta tailnet-wide route-selection mode. Its current documentation, validated October 7, specifies per-client priority scoring among eligible redundant subnet routers, app connectors and Tailscale Service hosts rather than grouping by DERP region. It also changes suggested exit-node scoring for clients running Tailscale v1.86.0 or newer. The beta is opt-in for Premium and Enterprise tailnets eligible for regional routing, and supports custom DERP servers. Existing route approvals, identity grants and prefix matching still apply.
Why it matters
Operators with multiple cloud regions, offices, SaaS connectors or Kubernetes clusters can change which eligible gateway each client uses without rebuilding Services or app connectors. That can improve route-selection flexibility for distributed workloads and custom DERP deployments, but it changes a tailnet-wide control-plane setting and must be tested. Priority scoring is not a promise of equal load, highest capacity, shortest latency or automatic cross-prefix failover.
A different choice from active-passive and regional routing
Tailscale's default active-passive mode chooses the oldest eligible connector and fails over when it becomes unavailable. Regional routing groups candidates by DERP region and uses client latency to select a region, but is incompatible with custom DERP servers. MagicRoute instead scores eligible candidates per client without DERP-region grouping, supports custom DERP servers and can select among redundant subnet routers, app connectors and Tailscale Service hosts. This is a routing policy change, not a replacement for WireGuard encryption or Tailscale's access-control model.
Who can opt in and what must be deployed first
The beta is limited to Premium and Enterprise tailnets eligible for regional routing; existing regional-routing users must explicitly opt in. Admins need Owner, Admin or IT admin privileges. Subnet routers must advertise the same approved route prefix to provide redundancy; app connectors must be configured for the same apps; Service hosts must be registered and approved. Server-side selection works across client versions, while MagicRoute's exit-node recommendation algorithm requires Tailscale client v1.86.0 or newer.
Changing the tailnet-wide setting has automation consequences
Admins can choose MagicRoute in the General page or set routeSelection to magicroute through the tailnet settings API with the feature_settings scope. Legacy automation that writes regionalRoutingOn can reset the selection to regional or active-passive; Tailscale advises using routeSelection for all four modes and not submitting both fields in the same PATCH. Existing Tailscale Services and Kubernetes Ingress resources need not be recreated when switching, but route assignments should be verified from clients in different locations.
Priority scoring is not a load-balancing SLA
Tailscale explicitly says MagicRoute does not guarantee even traffic distribution, capacity-based load balancing, selection of the geographically closest or fastest backend, or failover from a more-specific route to a broader prefix. Route eligibility and longest-prefix matching still govern connectivity. A saved setting alone does not establish which router actually served traffic: inspect client PrimaryRoutes in tailscale status --json and test representative destinations.
What is and isn't independently established
Official MagicRoute, route-selection, high-availability and Kubernetes documents give actionable setup and limitations. The October 19 blog URL appeared in BTN's queued feed but its page could not be fetched in this pass; the current official docs are the primary technical evidence. Independent multi-region latency, failover and capacity measurements have not been established. Beta availability and plan eligibility should be checked against the organisation's admin console before migration.