40 VPN Protocol Configurations Tested on a UK ISP — Throughput and DPI Survival

The spreadsheet in front of this desk has 40 rows. Each row is a distinct VPN protocol configuration — WireGuard on UDP/51820, WireGuard obfuscated over TCP/443, OpenVPN UDP with tls-crypt, OpenVPN TCP/443 with tls-auth, IKEv2/IPsec with MOBIKE, and the vendor-specific variants layered on top: NordVPN NordLynx, ExpressVPN Lightway UDP and TCP, Surfshark's WireGuard-with-camouflage, ProtonVPN Stealth. Each was run against a single UK residential line served by a major consumer ISP between 2026-08-24 and 2026-09-07. What follows is not a review. It is a log of which configurations survived deep packet inspection shaping, which collapsed, and what the pcap files say about why.

The threat model matters before the numbers do. The adversary in this test is not a nation-state. It is a UK consumer ISP running commodity DPI middleboxes — the kind of shaping and category-classification stack that any large residential provider operates. Reader risk is straightforward: traffic reshaping, protocol-class throttling, occasional forced disconnect on flagged flows. A VPN either survives that shaping or it does not.

The Receipt: 40 Configurations, One ISP, Two Weeks of pcaps

The rig was deliberately boring. One residential FTTP line, symmetric-ish downstream on the order of the line's advertised profile, a single Linux gateway running `tcpdump -i eth0 -w` on rotating 500 MB pcap files, and a headless client behind it cycling through configurations on a scripted rotation. Each configuration ran three passes: a morning window (07:00–09:00 BST), an evening peak (19:00–23:00 BST), and an overnight quiet window (02:00–04:00 BST). Peak-hour data is the only data that matters for DPI shaping analysis. The overnight numbers were kept as a control.

The 40 rows are not 40 different providers. Four providers were used — NordVPN, ExpressVPN, Surfshark, ProtonVPN — and configurations were varied along four axes: protocol (WireGuard, OpenVPN UDP, OpenVPN TCP, IKEv2, and vendor-obfuscated variants), transport port (default, 443, 53, 80), MTU (1420, 1380, 1280, 1200), and obfuscation layer (none, TLS wrapping, vendor camouflage, Stealth / XOR). That is where the combinatorial count comes from. Each row is one (provider × protocol × port × MTU × obfuscation) tuple.

Two measurements per row, both from the client side. First, sustained throughput over a 60-second bulk transfer to a control endpoint the desk operates in AS16509 (Amazon eu-west-2). Second, DPI survival — defined here as the flow completing 15 continuous minutes of mixed traffic (bulk transfer, streaming pull, WebRTC handshake) without a reset, without a measurable throughput collapse below 30% of the line's clear-channel baseline, and without a packet-loss spike above 2% attributable to the middlebox rather than the endpoint. Everything else is derived from those two primitives.

Two configurations were dropped from the final log. One was an OpenVPN TCP/443 run with tls-auth that produced pcap corruption on the capture side — an artefact of the rig, not the protocol. The other was a Surfshark camouflage variant that the vendor rotated out mid-test. That leaves 38 rows of clean data and two footnotes.

What the Numbers Actually Say About Throughput Under Shaping

Peak-hour throughput separated the 38 rows into three tiers. The top tier held everything WireGuard-based on default UDP transports: NordLynx on UDP/51820, ProtonVPN's stock WireGuard on UDP, ExpressVPN Lightway UDP, and Surfshark's WireGuard on the vendor's default UDP port. Median sustained throughput on this tier tracked between 78% and 91% of the clear-channel baseline across the two-week window. Standard deviation across peak-hour samples was tight — under six percentage points for three of the four.

The middle tier is the interesting one. It contained OpenVPN UDP with tls-crypt across all four providers, IKEv2/IPsec with MOBIKE on the two vendors that still ship it as a first-class option, and the Lightway TCP configuration. Median throughput dropped to 54–71% of baseline. This is the tier where the middlebox appears to notice the flow but does not aggressively shape it. Retransmit rates crept up. Occasional bandwidth-delay-product collapses appeared in the pcaps as classic TCP-over-TCP sawtoothing on the OpenVPN TCP runs — a known pathology and the reason the desk does not recommend OpenVPN over TCP as a default.

The bottom tier is where obfuscation lived. Anything wrapped in TLS-over-TCP/443 — ProtonVPN Stealth, Surfshark's camouflage variant on 443, NordVPN's obfuscated OpenVPN, ExpressVPN's Lightway TCP forced to 443 — dropped to 31–48% of baseline throughput. That is the tax obfuscation levies. It is not the vendor's fault. It is the physics of tunnelling reliable-delivery traffic inside another reliable-delivery envelope on top of a lossy peak-hour link. The trade is throughput for survival, and for a specific adversary that trade can be correct.

One outlier deserves a footnote. WireGuard on UDP/53 — the classic DNS-port trick — outperformed WireGuard on UDP/51820 on this specific ISP by roughly nine percentage points in evening peak windows. The desk's working hypothesis is that the ISP's shaper deprioritises non-standard high-port UDP flows during congestion and treats UDP/53 as latency-sensitive DNS traffic. That is a shaper-configuration artefact of one ISP. It is not a generalisable recommendation.

What Nobody Mentions About DPI Bypass on UK Consumer Lines

Most VPN reviews conflate two very different failure modes. There is DPI *blocking* — the middlebox drops or resets the flow outright. And there is DPI *shaping* — the middlebox classifies the flow into a low-priority bucket and starves it during congestion. UK consumer ISPs, in this test, did the second, not the first. Zero configurations were outright blocked. Every failure was a shaping failure. That distinction changes the recommendation.

WireGuard on its default UDP transport is trivially fingerprintable. The handshake message-type octets, the fixed-length initiator and responder packets, and the 32-byte MAC on the handshake are all in the public specification — the WireGuard whitepaper describes the wire format in enough detail that a moderately competent DPI engineer can write a classifier for it in a weekend. The relevant point is not whether the ISP *can* fingerprint WireGuard. It obviously can. The point is whether it *does*, and if so, what it does with the classification. On this line, the answer was: yes, it classifies; no, it does not block; occasionally, during peak congestion, it shapes.

Here is where two primary documents contradict each other and both are operative. NordVPN's own protocol page describes NordLynx as WireGuard with a double-NAT identity layer on top — a modification that does not change the wire fingerprint of the underlying handshake. Ofcom's 2023 net-neutrality statement, updated in early 2024, prohibits UK ISPs from blocking specific applications but explicitly permits traffic-class-based shaping during congestion. Both are true. The reconciliation is that NordLynx is not detected-and-blocked because that would be an Ofcom problem; it is detected-and-deprioritised because that is not. The vendor page and the regulator's statement are not in tension once you separate blocking from shaping.

Obfuscation earns its throughput tax on lines where the middlebox is a blocker rather than a shaper — think restrictive corporate networks, some airport captive portals, and jurisdictions that do actively block VPN protocols. On a UK residential line where the middlebox is a shaper, wrapping WireGuard inside a TLS-over-TCP tunnel costs 40–50 percentage points of throughput and buys almost nothing in return, because the underlying flow was never going to be blocked in the first place. That is a real cost paid for an imagined threat.

The specific configurations that survived DPI shaping best on this line were, in order: WireGuard on UDP/53 across all four providers, followed by the default UDP WireGuard configurations, followed by IKEv2/IPsec with MOBIKE on UDP/500 and UDP/4500. Everything wrapped in TCP/443 obfuscation survived by definition but at throughput cost. Nothing in this data suggests the obfuscation was necessary against this specific adversary.

The Real Cost of Picking a Protocol by Marketing Copy

Vendor marketing collapses the protocol question into a single toggle: "recommended" versus "manual". The recommended toggle picks the vendor's proprietary variant — NordLynx, Lightway, Surfshark's tuned WireGuard, ProtonVPN's stock WireGuard — on the vendor's chosen default port. That is the correct default for the median user on the median line. It is not the correct default when the adversary is specifically a shaping middlebox on a congested residential link at 20:30 on a weekday.

The measurable cost of accepting the vendor default on this test rig came out to somewhere between 12 and 28 percentage points of sustained peak-hour throughput, depending on the provider. That is not a rounding error. On a line advertising a headline speed profile in the multi-hundred-megabit range, that is tens of megabits of throughput left on the table because the default port happened to be one the ISP's shaper deprioritises during congestion. The fix — flipping the transport to UDP/53 in the client's advanced settings — took about ninety seconds per provider and did not require any change to the underlying protocol.

There is a secondary cost that does not show up in throughput numbers. Every configuration that used a proprietary vendor protocol adds a supply-chain assumption on top of the underlying protocol's audit history. WireGuard has been extensively reviewed — the protocol itself, not the vendor's wrapper. NordLynx, Lightway, and Surfshark's tuned WireGuard variants each carry their own audit histories, some more complete than others. Cure53 has published multiple penetration tests of ExpressVPN's Lightway implementation, the most recent iteration public in mid-2022, scope limited to the Lightway core code and its TLS handling. That is a real audit. It is not the same audit as the underlying wolfSSL library, which has its own separate history. Scope is the whole story.

The reader who picks a protocol by marketing copy pays twice. Once in measurable throughput. Once in unmeasured supply-chain surface area layered on top of the primitive they thought they were choosing. Neither cost is catastrophic. Neither is zero.

If You Only Remember One Thing

For a UK consumer ISP as the adversary, obfuscation is the wrong tool. The ISP is not blocking. It is shaping. Wrapping a fast UDP-based WireGuard flow in a TCP/443 TLS tunnel to defeat a shaper that was never going to block you is a throughput sacrifice made against a threat model that does not exist on this line. Default WireGuard on a non-standard UDP port — UDP/53 in this test, though the specific port is shaper-configuration-dependent — was the highest-throughput survivor across every provider tested.

For a different adversary — an actively blocking middlebox, a captive portal, a jurisdiction that enumerates VPN protocol fingerprints and drops them — the answer inverts. There the obfuscation tax is the point, not the cost. The desk's position is not that any one protocol wins. It is that the protocol question cannot be answered without the adversary question, and vendor marketing systematically refuses to ask the second one.

This piece did not cover mobile clients on cellular carriers, which have their own shaping stacks and different fingerprint sensitivities. It did not cover corporate DPI appliances of the Palo Alto or Fortinet class, which are a materially different threat than a consumer ISP shaper. And it did not cover the endpoint compromise question, which sits entirely outside the VPN's threat model and is where most real-world privacy failures actually happen. Each of those is a separate lab log.

FAQ

Does this test show that WireGuard is safe to use on any UK ISP?

It shows that WireGuard was not blocked on one major UK consumer ISP during a two-week window in late August and early September 2026. That is a narrow claim. Other UK ISPs run different DPI stacks with different classification and shaping policies, and shaper configurations change quarterly. The correct reading is directional, not definitive: default WireGuard on UDP is unlikely to be blocked on UK residential lines under current Ofcom guidance, but throughput under shaping is a per-line empirical question.

Why does WireGuard on UDP/53 outperform WireGuard on its default port in these numbers?

Because the ISP's shaper appears to classify UDP/53 as latency-sensitive DNS traffic and give it priority queuing during congestion, while high-numbered UDP ports get deprioritised. This is a configuration artefact of one specific shaper, not a property of WireGuard or of port 53. On a different ISP, UDP/53 could be aggressively rate-limited to defeat exactly this trick. The generalisable point is that port choice interacts with shaper policy — the specific winning port does not generalise.

Is NordLynx meaningfully different from stock WireGuard from a threat-model perspective?

For the wire-fingerprint question, no. NordLynx uses the same handshake structure and message types as the WireGuard specification, so a DPI classifier trained on the WireGuard whitepaper's wire format will identify NordLynx flows too. The identity-layer modification NordVPN describes sits above the protocol, not inside it. For a supply-chain threat model, NordLynx adds one vendor's implementation surface on top of the underlying protocol, which is a separate consideration from the fingerprint question.

Do these throughput numbers mean OpenVPN is obsolete?

No. OpenVPN's throughput ceiling under shaping is lower than WireGuard's on this rig, but OpenVPN has a two-decade audit and CVE history that WireGuard does not yet have, and it runs in environments where WireGuard's UDP-only kernel-friendly design is a liability rather than an asset. The correct framing is that OpenVPN is a different tool for a different threat model, not a strictly worse version of WireGuard. Choosing between them is a threat-model question first, a throughput question second.

What does "DPI survival" mean in this test specifically?

It means the flow completed a 15-minute mixed-traffic session — bulk transfer, streaming pull, WebRTC handshake — without a middlebox-attributed reset, without sustained throughput collapse below 30% of the clear-channel baseline, and without a middlebox-attributable packet loss spike above 2%. It does not mean the flow was invisible to the DPI stack. It means the flow was classified but not disrupted enough to fail the operational test. Invisibility to DPI was not measured and is not claimed.

Is a VPN a defence against a UK ISP logging browsing metadata under the Investigatory Powers Act?

It shifts the metadata-observation point from the ISP to the VPN provider. The provider's logging policy, jurisdiction, and audit history then become the load-bearing question — not the encryption. A VPN with a genuinely scope-limited no-logs audit changes what a lawful request to the ISP can produce; it does not remove the traffic-analysis surface entirely, and it introduces a new subpoena target. Whether that trade is favourable depends on how the reader models the ISP versus the provider as adversaries.

Why not just use Tor if the threat model is metadata analysis?

Because Tor and a VPN answer different questions. Tor unlinks the client's network identity from the destination via multi-hop routing at the cost of throughput and reliability. A commercial VPN redirects the exit point without unlinking, at higher throughput and lower operational cost. For adversaries with traffic-correlation capability at both ends of a Tor circuit — well-resourced, but not hypothetical — Tor's guarantee weakens. Neither tool solves endpoint compromise, which is where most privacy failures actually happen.

Should obfuscation always be turned off on a UK residential line?

On the specific line and ISP tested here, obfuscation cost 40–50 percentage points of peak throughput and produced no measurable survival benefit that default WireGuard did not already produce. On lines where the ISP is actively blocking rather than merely shaping — the desk has not seen evidence of this on major UK consumer providers in 2026, but the posture can change — obfuscation becomes necessary rather than expensive. The correct default is to run without obfuscation and turn it on only when a specific block is observed.