From 5acf494559f56b5041150afdcbf8af89d87fc623 Mon Sep 17 00:00:00 2001 From: Jack Carter <128555021+SunsetDrifter@users.noreply.github.com> Date: Wed, 22 Jul 2026 12:22:53 +0200 Subject: [PATCH] docs: add performance expectations section to exit nodes page (#873) * docs: add performance expectations section to exit nodes page * docs: qualify throughput figures and extend low-throughput checks --- .../use-cases/remote-access/exit-nodes.mdx | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/pages/use-cases/remote-access/exit-nodes.mdx b/src/pages/use-cases/remote-access/exit-nodes.mdx index fcf90048..89deddf0 100644 --- a/src/pages/use-cases/remote-access/exit-nodes.mdx +++ b/src/pages/use-cases/remote-access/exit-nodes.mdx @@ -99,6 +99,23 @@ Add a DNS server with the match domain set to `ALL`. Local DNS servers may not b See [Manage DNS in your network](/manage/dns) for details. +## Performance Expectations + +An exit node carries each device's entire internet traffic through a single WireGuard tunnel, and a single tunnel is processed largely on one CPU core of the exit node. This caps each device's throughput at single-tunnel speed: typically a few Gbps on a modern server CPU running Linux kernel WireGuard. The exact figure depends on the exit node's per-core speed, the tunnel MTU, and traffic direction (see the [benchmark assumptions](/manage/networks/sizing-routing-peers#per-peer-capacity-reference)), but it does not grow with parallel streams. + +Because this is a fixed cap rather than a percentage cost, what you observe depends on your internet line rate: + +- On links up to about 1 Gbps, an exit node typically adds little to no throughput loss. +- On multi-gigabit links, full-tunnel throughput tops out at the tunnel cap, so a large relative drop against a 5 or 10 Gbps line is expected behavior, not a misconfiguration. + +A common mistake is scaling the wrong dimension: adding CPU cores to the exit node or running more parallel streams on a device does not raise that device's ceiling, because the tunnel still serializes on one core. Per-core CPU speed does raise it, so for fast individual clients pick the exit node hardware with the fastest single-core performance available. More cores raise the aggregate capacity across many devices; see [Sizing Routing Peers](/manage/networks/sizing-routing-peers#per-peer-capacity-reference) for measured per-size numbers. + +If throughput lands well below a few Gbps, check these before resizing hardware: + +- **Relayed connection.** Run `netbird status -d` on the device and confirm the connection to the exit node shows type P2P. Relayed traffic is significantly slower than a direct connection. +- **Userspace WireGuard.** Devices on Windows and macOS, and peers running in [userspace mode](/manage/networks/sizing-routing-peers#userspace-mode), reach well below kernel-mode numbers. +- **Exit node limits.** If the connection is P2P and both ends run kernel WireGuard, check the exit node's CPU load, the tunnel MTU, and the traffic direction against [Tuning for more throughput](/manage/networks/sizing-routing-peers#tuning-for-more-throughput). + ## IPv6 Support