sendnrw/netbird-docs
2
0
Fork 0
mirror of https://github.com/netbirdio/docs.git synced 2026-08-25 01:01:27 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: add performance expectations section to exit nodes page (#873)

Browse Source 
* docs: add performance expectations section to exit nodes page

* docs: qualify throughput figures and extend low-throughput checks
This commit is contained in:
Jack Carter
2026-07-22 12:22:53 +02:00
committed by GitHub
parent accc461a7e
commit 5acf494559
1 changed files with 17 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
src/pages/use-cases/remote-access/exit-nodes.mdx
View File

@@ -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
<Note>