![\"ellipsis](\"https://tailscale.com/files/images/icons/fa-ellipsis-h.svg\"){kind=icon}
menu at the end of the table, select Review subnet routes. This will open up the Subnet settings.Last validated: Oct 3, 2025
\nWhen using subnet routers or app connectors in large networks, you may want to set up high availability to ensure users of your network can continue to access resources if one routing device goes offline, or to increase performance across a global workforce. Tailscale offers two methods of building redundancy into a network.
\nFailoveris available for all plans.
\nFailover lets customers deploy overlapping connectors (that is, app connectors that advertise the same apps, or subnet routers that advertise the same routes). In a failover scheme, one connector is used at a time by all clients. If it goes offline another connector is used.\r\nConnector selection occurs in the order of the dates when you added the connectors to the tailnet. The oldest connector is the \"primary\", and failover occurs in oldest-first order. Failover can take up to ~15 seconds after a primary connector goes offline.
\nFailover is the default behavior: overlapping connectors will automatically exhibit this behavior, which is available on all plans.
\nRegional routingis available for the Premium and Enterprise plans.
\nRegional routing lets customers deploy a global fleet of overlapping connectors (that is, app connectors that advertise the same apps, or subnet routers that advertise the same routes). Overlapping connectors are grouped into regions that map to Tailscale's DERP regions.
\nUpon connecting to Tailscale, client devices identify which regional routing group is closest to them by finding the closest DERP server. This works by having clients report their latencies to the nearest active DERP servers, after which clients are assigned a regional routing group. Each client is then instructed to send traffic bound to a given applicable destination directly to the closest connector. The client re-evaluates its choice of regional routing group periodically. If a region no longer has available connectors, another region is used, giving the network global high availability and improved performance for a global workforce.
\nIf multiple overlapping connectors exist within a region, the specific connector used within that region depends on one of two behaviors:
\nWithin a DERP region, if multiple overlapping connectors exist, then load is spread evenly across the connectors on a best-effort basis. The algorithm is as follows: each client has a stable pseudorandom order of routing preference for the set of nodes in a region. If the top preferred node is unavailable the client is directed to the next most preferred node. As a side effect, this behavior creates a \"stickiness\": clients will be routed to a specific connector within a region, unless that connector is unavailable.
\nAn admin can request to disable in-region load balancing and instead opt for in-region failover when regional routing is enabled. To disable in-region load balancing while regional routing is enabled, contact support and request in-region failover when using regional routing. Failover exhibits the behavior described in Failover, limited to the scope of a single DERP region.
\nThe traffic for Tailscale clients will automatically be routed to the nearest region with an active overlapping connector. This is a global preference; all overlapping connectors will exhibit the same tailnet-wide settings.
\nYou can use subnet routers in conjunction with regional routing to on-ramp remote employee traffic to transit gateways such as AWS Transit Gateway, Google Cloud Interconnect, Azure ExpressRoute, and other virtual private transit providers. By placing a subnet router in front of each network on-ramp point, regional routing will automatically route device traffic on to the transit provider as quickly as possible.
\nYou can use subnet routers in conjunction with regional routing to connect to applications or VPCs that are globally replicated across your cloud provider's regions, or across multiple cloud providers. By placing a subnet router in front of each application or VPC, regional routing will automatically route device traffic on to the nearest version of that application or VPC. When using this methodology, the application must be available from the same set of IP addresses within the same high availability subnet route. In this way, you can easily deploy and connect to a globally distributed application, with multi-cloud failover built right in.
\nYou can use app connectors alongside regional routing to connect to SaaS apps from a globally distributed workforce to increase performance for your entire organization, while maintaining necessary access controls. By placing an app connector near each office or branch, regional routing will automatically route device traffic on to the nearest app connector, and out to the target SaaS app. In this way you can deploy and connect to SaaS, with performance and reliability built right in.
\nFollow our guide to configure app connectors, assigning all app connectors to the same tag. For example, to create multiple app connectors on the tag:connector, you'll want to run a command like this on 2+ machines.
sudo tailscale up --advertise-connector --advertise-tags=\"tag:connector\"\nFollow our guide to configure app connectors, assigning an app to multiple app connectors by using the same tag:connector tag.
Once you have 2+ app connectors exposing the same apps on the same network,\r\nthe Tailscale control server will automatically manage the failover between\r\nthe different connectors. In failover mode, if an app connector is disconnected from the\r\ncontrol plane for more than 15 seconds, traffic will be routed to another\r\napp connector. In regional routing mode, if the connectors are in different regions, clients will be assigned to each based on their closest available DERP region.
\nFollow our guide to configure subnet routers, exposing the same routes on the same network on 2+ devices. For example, to expose 10.0.0.0/24,10.1.0.0/24, you'll want to run a command like this on 2+ devices.
sudo tailscale set --advertise-routes=10.0.0.0/24,10.1.0.0/24\nYou can configure as many subnet routers as you want to act as a failover.
\nFailover only works between subnet routers that advertise the exact same route prefix. A broader route does not serve as a fallback for a more-specific route.
\nFor example, if one subnet router advertises 10.0.0.0/24 and another advertises 10.0.0.0/16, they are not failover candidates for each other. If the /24 router goes offline, Tailscale drops traffic to 10.0.0.0/24 rather than falling back to the /16 route.
To configure failover correctly, have multiple subnet routers advertise the same routes:
\n# Run on 2+ subnet routers to enable failover for both prefixes\r\nsudo tailscale set --advertise-routes=10.0.0.0/24,172.16.5.0/24\nIf you need a broader route to also serve as a fallback for a more-specific prefix, configure the broader-route router to advertise both prefixes. For more information, refer to overlapping subnet route failover.
\nWhen setting up subnet routers for high availability (HA), be careful with the --accept-routes flag. If you turn on --accept-routes for subnet routers that share the same routes in the same region, the standby router will accept its own advertised routes from the primary router.
This leads to an inefficient routing path. The standby router will send traffic for its directly connected subnet through the primary router instead. For example, if both subnet routers advertise and accept the same route, such as 192.168.1.0/24, the standby router will send all 192.168.1.0/24 traffic through the primary router, even though it is directly connected to that network.
For most HA subnet router setups, use the --advertise-routes flag alone. Avoid using --accept-routes unless you specifically need that routing behavior.
Open the Machines page of the admin console, locate your subnet router and using the menu at the end of the table, select Review subnet routes. This will open up the Subnet settings.
Select Enable on your routes so that Tailscale distributes the subnet routes to the rest of the nodes on your Tailscale network.
\nYou may want to disable key expiry on your server to avoid having to periodically reauthenticate. Refer to key expiry for more information about machine keys and how to disable their expiry.
\nOnce you have 2+ subnet routers exposing the same route on the same network,\r\nthe Tailscale control server will automatically manage the failover between\r\nthe different routers. In failover mode, if a subnet router is disconnected from the\r\ncontrol plane for more than 15 seconds, traffic will be routed to another\r\nsubnet router. In regional routing mode, if the subnet routers are in different regions, clients will be assigned to each based on their closest available DERP region.
\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")