WireGuard benchmark on Linux, Oct 2026

On 2026-10-30, on x86_64 Linux virtual machines in our lab, Quantum, ForestVPN's tunnel engine, carried more single-stream TCP traffic than wireguard-go wherever the network link was not the limit: 1.33 to 2.67 times as much with each side held to 1, 2 or 4 vCPUs, and 1.35 to 1.79 times between two VMs on one host, with Quantum set to as many threads as vCPUs (its default is one) (home-lab run). Over a 2.5 Gbit/s link, Quantum, wireguard-go and kernel WireGuard all reached about 95 percent of the link: a tie (home-lab run). For each gigabit carried, wireguard-go spent 1.7 to 2.6 times Quantum's CPU above the no-tunnel baseline, with Quantum in whichever setting cost it less (mostly one thread, because more threads cost more CPU per gigabit); our target was 2.5 times, met in 2 of 12 measurements and in no single-stream one. Quantum lost on latency under load to kernel WireGuard and boringtun. Nothing here describes phones, Macs, Windows PCs or routers.

How was this WireGuard benchmark run?

Three setups in our lab, every comparison inside one run with its own no-tunnel control, five runs per cell in shuffled order, the minimum and maximum kept next to every median.

Quantum speaks WireGuard's unmodified Noise_IKpsk2 handshake (the Noise protocol pattern WireGuard uses, with a pre-shared key); the protocol page has the details. We measured throughput with iperf3.

Which tunnel carried the most traffic?

Where the CPU was the limit, Quantum with as many threads as vCPUs carried more than wireguard-go at every core count we ran (home-lab run). At one thread on 4 vCPUs it carried less.

Show the data

Quantum, 1 thread	10717 Mbit/s
wireguard-go	4016 Mbit/s
boringtun, 1 thread	3422 Mbit/s

With threads set to the vCPU count, Quantum carried 2.67, 1.67 and 1.33 times wireguard-go's traffic at 1, 2 and 4 vCPUs, and the ranges do not overlap (home-lab run). At one thread it carried 1.43 times at 2 vCPUs and 0.94 times at 4: less. Kernel WireGuard is left out of this table, because its encryption runs in kernel threads we cannot hold to the same vCPUs, so it is not a matched comparison. With one vCPU and one thread each, boringtun (Cloudflare's userspace WireGuard in Rust) carried 3422 Mbit/s; its other figures in this lab are unexplained (see below), so that is the only boringtun result we use (home-lab run).

Show the data

Quantum, 4 threads	10030 Mbit/s
Quantum, 1 thread	7553 Mbit/s
wireguard-go	7438 Mbit/s
Kernel WireGuard	4513 Mbit/s

Between two VMs on one host, Quantum with threads set to the vCPU count carried 1.79 times wireguard-go's traffic at 2 vCPUs and 1.35 times at 4 (home-lab run). At one thread and 4 vCPUs the two tied: 7553 against 7438, with overlapping ranges. Kernel WireGuard carried less than Quantum at both sizes, and less at 4 vCPUs than at 2, in this run and in the OpenVPN run the same day; we have not found why, so read its 4-vCPU figure with care.

Over a 2.5 Gbit/s link between two hosts, the plain connection carried 2272 Mbit/s and Quantum 2164, wireguard-go 2170 and kernel WireGuard 2168 (home-lab run). That is a tie at the link, and we rank nothing there.

How much CPU does each gigabit cost?

Less for Quantum than for wireguard-go in every measurement, but by the 2.5 times we aimed for in only 2 of 12 (home-lab run).

Two of the twelve met the target, both with four streams: 2.63 (worst run 2.61) and 2.57 (worst run 2.44). On one stream the ratio stayed between 1.72 and 2.10 (home-lab run). More threads bought throughput at up to 22 percent more CPU per gigabit than one thread, so Quantum's highest throughput and its lowest CPU cost come from different settings.

Between two VMs on one host, where the processor's counters were visible, the whole host spent 13.1 CPU cycles per delivered byte with Quantum at one thread and 12.7 at 2 threads (2 vCPUs), and 13.8 and 15.0 at 1 and 4 threads (4 vCPUs), against 22.8 and 25.5 for wireguard-go (home-lab run). The count includes iperf3 and the kernel network stack, so it compares tunnels within this setup only.

How much memory does each tunnel use?

boringtun was the smaller of the two Rust tunnels on the one-VM setup, so we do not call Quantum the smallest (home-lab run). More threads cost Quantum 0.9 to 1.3 MB (home-lab run). wireguard-go's memory grows with the traffic it has carried, which is why the one-VM figures, read over a whole run, are higher. Kernel WireGuard runs no comparable process.

What happens to latency under load?

Quantum lost here. While one TCP stream ran between two VMs on one host, its ping p99 was 4.72 ms at one thread and 5.69 at 2 threads (2 vCPUs), and 4.74 and 4.03 at 1 and 4 threads (4 vCPUs) (home-lab run). Kernel WireGuard had 2.27 and 3.12 ms, boringtun 1.83 and 1.61, wireguard-go 10.0 and 6.28 (home-lab run). Over the 2.5 Gbit/s link Quantum, wireguard-go and kernel WireGuard all sat near 8 ms (home-lab run). Each tunnel was measured at its own throughput, and boringtun carried far less, but we report the result as a loss (home-lab run).

How does Quantum compare with OpenVPN?

In a separate run the same day, between two VMs on one host (OpenVPN run):

Quantum carried 2.5 and 2.8 times what OpenVPN with DCO did and 16 and 14 times userspace OpenVPN, at 12.7 and 14.2 CPU cycles per byte against DCO's 22.6 and 23.6 (OpenVPN run). OpenVPN moves one stream through one process or one kernel path, so it had no extra threads to use: this is each tunnel as it runs, not matched cores. OpenVPN won on latency (OpenVPN run): ping p99 under that load was 1.43 and 1.85 ms with DCO and about 1.5 ms in userspace, against Quantum's 5.52 and 3.92. Over a 2.5 Gbit/s link (OpenVPN run), every tunnel but userspace OpenVPN reached the link, and DCO used the least host CPU per gigabit of any, 0.48 CPU seconds against Quantum's 0.67 (whole host, no-tunnel baseline not subtracted). OpenVPN used AES-256-GCM and the WireGuard family ChaCha20-Poly1305. These figures are about OpenVPN 2.7.0 and are not compared with the main run's.

What changed since our earlier Linux runs?

The code. In the same run, the build of Quantum before these changes carried 2.2 to 3.1 times less on one stream (4855 Mbit/s against 10717 at 1 vCPU) and had 35000 to 42000 TCP retransmissions per 15 s window where the new build had none (home-lab run). The new build spends 14 to 25 percent less CPU per gigabit at one thread in the one-VM and same-host setups. It also has a higher ping p99 under load (home-lab run), 3.3 ms against about 0.4 on one VM (the old build dropped packets where the new one queues them), spends 6.6 percent more CPU per gigabit on one stream over the 2.5 Gbit/s link, and holds 0.7 to 0.9 MB more memory at one thread.

What changed is how the Linux daemon receives (it now takes the batches the kernel coalesces), a fix for datagrams the old receive loop dropped after the kernel had handed them over, and, with --threads above 1 on Linux, encryption on helper threads. The handshake and the wire format did not change.

Our 2026-10-16 and 2026-10-17 runs on Scaleway servers measured the build before these changes, and there kernel WireGuard and wireguard-go carried about two to three times Quantum's traffic (earlier build). They stay on the compare page as the earlier build. They used other machines, kernels and builds, so we compare nothing across them, and they do not measure what the changes gained (home-lab run).

Where did Quantum lose or tie?

• Latency under load: higher than kernel WireGuard's, boringtun's and OpenVPN's, in every setup where they could be told apart.
• The 2.5 Gbit/s link: a tie with wireguard-go and kernel WireGuard (home-lab run).
• CPU target: 2.5 times wireguard-go's efficiency in 2 of 12 measurements, none on one stream.
• One thread on 4 vCPUs: 0.94 times wireguard-go's traffic on one VM, a tie between two VMs.
• Many peers: with 16 peers on one endpoint, Quantum at 4 threads shared the traffic less evenly than wireguard-go and dropped frames that wireguard-go did not. That run had a smaller VM than planned, so we publish no figure from it.

What does this benchmark not show?

• Other platforms: nothing here carries over to phones, tablets, Macs, Windows PCs, routers or the apps, and none of them was measured in these runs. The router figures come from a separate run on 2026-09-01.
• The packaged build: we ran a glibc build from source; the packages ship a static build, and on 2026-10-30 no published release contained these changes (home-lab run).
• A real WAN: every setup is virtual machines in one lab, and other projects' VMs shared the hosts.
• Kernel WireGuard as a matched rival: on one VM it could not be held to the same vCPUs, and between VMs it carried less at 4 vCPUs than at 2 for reasons we have not found.
• boringtun outside one vCPU: its figures fell with more threads and between VMs, which we have not explained.
• UDP, connect time and production settings: no UDP or connect-time figures, and the optional extra key exchange that production servers run was off.
• Across runs: we never divide a figure of one run by one from another.

Which tunnel should you pick on a Linux server?

Where the CPU is the limit, Quantum with --threads set to the core count carried more single-stream traffic than wireguard-go and boringtun in every setup we ran, and more than kernel WireGuard and OpenVPN between two VMs on one host. If latency under load matters more than throughput, kernel WireGuard and OpenVPN with DCO had the lower figures. If the link is the limit, as at 2.5 Gbit/s here, the WireGuard-family tunnels all reached it (home-lab run), and the choice comes down to everything else. Choose Quantum too if you want ForestVPN's engine on a Linux server.

What changed on this page

• 2026-10-30: rewritten around the 2026-10-30 home-lab run of the current build and a same-day OpenVPN run; the 2026-10-16 and 2026-10-17 Scaleway runs of the earlier build moved to the compare page.