My connection tested at 260 Mbps with the VPN turned on, on a gigabit fiber line rated for 940 Mbps — a home network I've spent way too long tuning. That gap between what I pay for and what actually reaches my laptop is the whole subject of this piece, and almost none of the marketing copy for any VPN service explains where the missing bandwidth actually goes.
The short answer, if you want it before the explanation: look for a VPN client running a modern, kernel-level protocol rather than an older standard, and don't assume your router can handle gigabit encryption for your whole home network just because it handles gigabit routing (those are, annoyingly, two completely different jobs). Most consumer hardware is only really built for one of them.
I run this testing out of a room in my house in Seattle's Beacon Hill neighborhood, where a couple of small machines sit stacked on a shelf logging speeds around the clock and a whiteboard next to the desk has accumulated more crossed-out configuration notes than legible ones. After a long run of continuous logging, that stack of machines throws off enough heat that I can feel it standing a few feet away, which is a strange thing to notice about network equipment, but there it is.
The Router Is Usually the Real Bottleneck, Not the VPN
Gigabit Ethernet marketing promises 1000 Mbps, but the realistic ceiling on Gigabit Ethernet sits closer to 940, once you account for ordinary TCP/IP overhead. Add a VPN to that path and every packet also needs wrapping and encrypting with something like the Advanced Encryption Standard (AES), which is computationally expensive at real gigabit volume. Most consumer routers are built to move packets fast, not to do that kind of math on every single one of them in real time, so the CPU pins itself long before the network card ever does.
Running the VPN directly on your router protects every device in the house without installing separate clients, which is genuinely convenient. But consumer router CPUs cap encryption throughput long before the fiber line itself does, so router-level VPN is trading your ceiling speed for that convenience — a fine trade for a phone or a smart TV, a bad one if you're the person actually trying to push real gigabit numbers through your main machine. I picked apart this exact hardware-versus-protocol divide in more detail in my 30 days and 450 speed tests comparison, if you want the raw logs.
Protocol Architecture Changes the Math More Than Marketing Admits
Protocol choice is where most of that CPU tax actually gets decided. WireGuard-based implementations run at the kernel level, which typically means less encryption overhead than older standards like OpenVPN or IKEv2. Point two identical servers at the same hardware and the kernel-level tunnel usually wins on real throughput — though that gap narrows a lot once both sides have enough CPU headroom to spare, since the older protocols aren't actually starved for compute anymore at that point.
That's also why comparing VPNs by server count alone misses the point (server count makes for a great marketing slide, not a great throughput predictor) — a service with thousands of servers running an inefficient protocol will still lose to a leaner implementation with a fraction of the network, once you're actually pushing gigabit-class traffic through it.
What My Own Speed Tests Actually Confirm
On my own gigabit line, a well-optimized kernel-level tunnel holds throughput in the 800 Mbps range consistently, even during the evening hours when a lot of Seattle's residential traffic is competing for the same trans-Pacific fiber routes. That's not a marketing number; it's what a repeated VPN speed test on my own home network actually shows, run over and over until the average stops moving.
Packet captures are the other half of that confirmation, because raw speed doesn't tell you whether the tunnel is actually doing its job. Pull up Wireshark during a session and a working tunnel shows only the VPN's exit address in the traffic — my actual home IP doesn't show up anywhere in the capture, which is the boring, unglamorous way to confirm the encryption is wrapping everything and not just the convenient parts.
Security Habits a Fast Tunnel Still Won't Cover
Speed and privacy aren't the same axis, and I learned that one the annoying way. For a stretch when I was being more careful than usual about where my traffic went, I routed my personal traffic through my employer's corporate VPN client because it was already installed and free — right up until I actually read the acceptable-use policy and realized IT was logging every connection running through it, banking and personal email included, sitting in a log file that had nothing to do with work. A personal VPN's whole job is keeping that traffic private from everyone, including whoever issued your laptop.
A kill switch matters more than people expect here too — if the tunnel drops mid-session, you want the connection to fail closed instead of quietly falling back to your raw ISP link without telling you. DNS leak protection is worth checking on its own, separate from throughput, since a tunnel can hold gigabit speeds and still send your lookups straight to your ISP's resolver if it's misconfigured. Some of the slowdown people blame on the VPN itself is actually the ISP recognizing and classifying encrypted traffic differently once it can no longer see what's inside the packet. Whether a provider's no-logs claim actually holds up under an independent audit is a separate question from all of this, and one worth checking before you trust a service with anything sensitive. None of it matters much until you've scoped out what you're actually defending against — a person worried about a nosy roommate needs a very different setup than someone worried about a corporate legal team.
Matching the Tool to the Job, Not Just the Speed Test
Raw throughput also isn't the only variable worth optimizing for, and conflating it with everything else a VPN can do is where a lot of buying decisions go sideways. Split tunneling is a completely different question from speed — it's about which apps go through the tunnel at all, useful if you want your smart-home devices talking to your phone without also routing through the VPN. A dedicated IP solves a different problem again, mostly around not getting flagged as suspicious by services that dislike shared exit nodes, and has nothing to do with how fast your connection tests. Port forwarding matters a lot if you're self-hosting something or moving large files, and barely at all if you're just browsing, so it's worth checking before you rule a client out over a missing speed number. A browser-only proxy extension isn't the same animal as a full system tunnel either, since it protects one tab and leaves everything else — your game console, your torrent client — running bare.
That protocol efficiency is also part of why kernel-level tunnels get cited as a reliable choice for online gaming, where latency matters more than raw throughput ever does. Getting a tunnel to unlock something that's geographically restricted is a genuinely separate use case from anything I've measured here, and one I'd rather point toward a dedicated writeup than half-cover in a speed article. My partner, Lila, mostly just wants to know if the numbers went up or down, and gets visibly impatient the moment I try to explain why a config change took twenty minutes instead of two, which is probably the correct amount of interest for someone who works in UX design and never signed up to co-own a home lab.
None of this requires a dozen subscriptions to work out for yourself, even though I apparently needed that many (more than a dozen, at last count) to feel sure about it. Check whether the protocol is kernel-level and modern before anything else, confirm your router isn't the thing capping you by testing with the VPN running on a wired connection to a real computer instead of the router itself, and only then start comparing server counts or price. On a genuinely fast fiber line, the tunnel should be the thing you forget is running, not the thing you're troubleshooting every week.