Update docs for new HA tracking

Also shorten the description in config-example.yaml a bit.
This commit is contained in:
Florian Preinstorfer
2026-04-17 16:46:30 +02:00
committed by nblock
parent 1b6ab52f9e
commit 813eb2d733
2 changed files with 6 additions and 14 deletions

View File

@@ -167,10 +167,6 @@ node:
# HA subnet router health probing.
#
# A subnet router can hold its control-plane session open yet be unable to
# forward traffic ("zombie connected"). The normal disconnect-based failover
# never fires because the Noise session is still alive.
#
# When HA routes exist (2+ nodes advertising the same prefix), headscale
# pings each HA node every probe_interval via the Noise channel. If a node
# fails to respond within probe_timeout it is marked unhealthy and the
@@ -179,7 +175,6 @@ node:
#
# Worst-case detection time is probe_interval + probe_timeout (15s default).
# No-op when no HA routes exist. Set probe_interval to 0 to disable.
# probe_timeout must be less than probe_interval.
routes:
ha:
# How often to ping HA subnet routers. Set to 0 to disable probing.

View File

@@ -287,16 +287,13 @@ information on auto approvers.
## High availability
Headscale has limited support for high availability routing. Multiple subnet routers with overlapping routes or multiple
exit nodes can be used to provide high availability for users. If one router node goes offline, another one can serve
the same routes to clients. Please see the official [Tailscale documentation on high
availability](https://tailscale.com/kb/1115/high-availability#subnet-router-high-availability) for details.
Headscale supports high availability routing. Multiple subnet routers with overlapping routes or multiple exit nodes can
be used to provide high availability for users. If one router node goes offline, another one can serve the same routes
to clients. Please see the official [Tailscale documentation on high
availability](https://tailscale.com/docs/how-to/set-up-high-availability#subnet-router-high-availability) for details.
!!! bug
In certain situations it might take up to 16 minutes for Headscale to detect a node as offline. A failover node
might not be selected fast enough, if such a node is used as subnet router or exit node causing service
interruptions for clients. See [issue 2129](https://github.com/juanfont/headscale/issues/2129) for more information.
This feature is enabled by default when at least two nodes advertise the same prefix. See the configuration options
`node.routes.ha` in the [configuration file](./configuration.md) for details.
## Troubleshooting