{"id":50026,"date":"2026-09-16T10:00:00","date_gmt":"2026-09-16T10:00:00","guid":{"rendered":"https:\/\/hubhide.com\/?hubhide_en=1025"},"modified":"2026-10-01T10:52:00","modified_gmt":"2026-10-01T10:52:00","slug":"vpn-protocols-2026","status":"publish","type":"post","link":"https:\/\/hubhide.com\/blog\/en\/vpn-protocols-2026\/","title":{"rendered":"VPN Protocols 2026: A Complete Guide to PPTP, L2TP, IKEv2, OpenVPN, WireGuard and VLESS"},"content":{"rendered":"
\n

Open the VPN settings on any operating system and you will see a list of half a dozen abbreviations. Some should not be touched at all, some worked perfectly fifteen years ago, and the thing you actually need today is usually not on that list.<\/p>\n

The protocol list looks like a geological cross-section, and I like that image more than any other: each layer belongs to an era of the Internet \u2014 when nobody monitored anyone, when monitoring began, and when people started actively interfering as well. New layers settle on top; old ones do not disappear. They simply stop handling the load.<\/p>\n

I will go through them one by one, with judgments and without trying to make excuses for anyone. I have used most of them personally, in different years and with varying degrees of pleasure, so I will be subjective in places and admit that upfront. There is a summary table at the end \u2014 if you only need the answer, skip there.<\/p>\n

What a VPN Protocol Actually Consists Of<\/h2>\n

First, let us agree on what exactly we are comparing. \u201cProtocol\u201d is a word different people, as I have noticed, use to mean very different things.<\/p>\n

What is a VPN protocol when you break it down? A set of agreements that lets two sides understand each other. There are exactly three kinds of agreements.<\/p>\n

Transport. How the data travels \u2014 TCP or UDP, which port is used, and how packet loss is handled. This affects both speed and whether the tunnel gets through filters. TCP guarantees delivery order and therefore slows down on poor links; UDP guarantees nothing, but it is fast.<\/p>\n

Encryption. What protects the contents. Modern cipher suites include integrity checks, so you immediately notice data being modified in transit. Older ones did not, which is one reason ancient protocols are dangerous.<\/p>\n

Authentication. How the sides verify that the other party is trusted: password, certificate, key pair or identifier. Interestingly, this is where protocols have historically failed most often: not by breaking the cipher, but by bypassing the verification.<\/p>\n

How do VPN protocols differ? By the decisions made at each of those three points. Everything else follows from them, and once I formulated it that way for myself, half the arguments on the Internet stopped looking meaningful.<\/p>\n

One more observation to keep in mind throughout: speed and invisibility are usually inversely related. A fast protocol uses the channel aggressively and therefore stands out. An unobtrusive one behaves like ordinary web traffic and is constrained by its limitations. There is no universal leader, and I suspect there never will be.<\/p>\n

[Image: protocol stack diagram \u2014 transport, encryption, authentication]<\/em><\/p>\n

PPTP: Do Not Use It. Ever<\/h2>\n

I will start with the only one about which I have absolutely no doubts.<\/p>\n

PPTP appeared in the 1990s, when the Internet was small and trusting, and I remember it well \u2014 it was the first tunnel I ever set up, around 2009, and it fascinated me at the time. Fast. Built into every system. Configured in a minute, with no certificates, no configs and no console commands. And yet it has long been completely and irreparably broken. The problem is in authentication: the scheme it relies on can be cracked computationally in a reasonable time with ordinary hardware, and no setting can fix that because the flaw is in the protocol design, not the implementation. It also handles NAT poorly and often fails in hotel and office networks. A latch you can open with a fingernail: it looks like protection, but does not protect.<\/p>\n

It is still present in router menus and cheap-service lists because it is inexpensive to support. If a provider offers PPTP as its main option, that tells you more about the provider than any review.<\/p>\n

L2TP\/IPsec: Alive, but Without Enthusiasm<\/h2>\n

Next comes a two-part combination that causes confusion with remarkable consistency. I was confused by it myself once.<\/p>\n

L2TP itself encrypts nothing. At all. It only creates a tunnel \u2014 a pipe through which data travels \u2014 while IPsec, layered on top, provides encryption. That also answers the perennial question of how L2TP differs from IPsec: they are not competitors but layers of one construction; one carries the data, the other locks it, and neither is a complete solution on its own.<\/p>\n

IPsec cryptography is solid; the complaints are about everything around it. Double encapsulation costs performance. Fixed ports mean the whole combination can be blocked with one rule. NAT compatibility is poor and needs a separate traversal mechanism. Another pain point is the shared key: in many configurations the same secret is used by all users, and if one person leaks it, everyone has to be reconfigured. I once cleaned this up at a small company, and it was, let us say, an educational week.<\/p>\n

Where you will find L2TP today: old corporate infrastructure that nobody touches because \u201cif it works, do not touch it.\u201d It is not suitable for bypassing blocks.<\/p>\n

IKEv2\/IPsec: The One That Survives the Subway<\/h2>\n

Now this is a solid protocol, and I think it is discussed far too rarely.<\/p>\n

What is IKEv2? It is a secure-connection establishment mechanism that works together with IPsec. There are open implementations, and it is built into iOS, macOS, Windows and Android.<\/p>\n

Its main feature is called MOBIKE and lets a connection survive a network change: you leave home, the phone switches from Wi-Fi to mobile data, the address changes \u2014 but the tunnel does not collapse; it simply moves to the new network. For a phone, that is critical. That is why IKEv2 was the default protocol in mobile apps for years, and on Apple devices it still feels particularly native. Speed is good, reconnection is fast and battery usage is reasonable. I kept it on my work phone for about three years and never had to think about it \u2014 which, honestly, is one of the best compliments you can give network software.<\/p>\n

There is exactly one downside, but in our environment it is decisive: known ports and a recognizable profile. It is easy to block. As a daily tool on an unrestricted network, excellent; as a bypass tool, no.<\/p>\n

SSTP: A TLS Wrapper Tied to One Platform<\/h2>\n

A short section: honestly, there is not much to tell.<\/p>\n

SSTP wraps the tunnel in TLS and uses port 443, so the logic is similar to OpenVPN over TCP: look like ordinary HTTPS and get through that way. When it appeared, the idea was fresh.<\/p>\n

The first problem is platform dependence: natively it lives in the Windows ecosystem, while support elsewhere is limited. The second is the same issue OpenVPN over TCP has. Similar does not mean indistinguishable, and TLS fingerprinting can expose it to anyone who knows what to look for. A corporate infrastructure that is entirely Windows-based can use it; I will not argue with that. Everywhere else, there are better options.<\/p>\n

OpenVPN: The Twenty-Five-Year-Old Workhorse<\/h2>\n

All right, now for the thing that is actually used every day.<\/p>\n

OpenVPN appeared in the early 2000s and has accumulated almost everything you could want: TCP and UDP, any port, certificates, access revocation, two-factor authentication and rule-based routing. Open source, independent audits, support almost everywhere, practically even on a toaster. You pay for that flexibility with performance: it runs in user space and moves packets between system layers, which is very noticeable on a weak CPU, especially on routers. In my view, the second price of flexibility is worse: you can configure it badly. A configuration with server-certificate verification disabled will still work: the icon turns on and the speed looks normal. The protection simply is not there, and the user may never know.<\/p>\n

TCP on port 443 is the reason OpenVPN was considered a bypass tool for an entire decade. Today that advantage can disappear within weeks, and I am a little sorry about that. A detailed comparison is in the WireGuard vs OpenVPN article<\/a>.<\/p>\n

WireGuard: Minimalism Taken to the Limit<\/h2>\n

The complete opposite of the previous protocol philosophically. Not in quality \u2014 specifically in philosophy.<\/p>\n

A few thousand lines of code instead of tens of thousands, one fixed cryptographic suite instead of a cabinet full of options, UDP only instead of a choice of transport. No modes, no options, no \u201ccan we do it this way?\u201d The result is impressive. It is fast \u2014 on a good link, the difference from OpenVPN is obvious. It is efficient, and the phone battery lasts noticeably longer. It connects almost instantly because the handshake takes a couple of packets instead of a full TLS session. It also survives network changes: the server accepts packets from a known key regardless of the source address, so moving from Wi-Fi to mobile data is seamless. And the compact codebase can actually be audited in full, which is a rare luxury.<\/p>\n

It has two weak points. Recognizability: UDP only, fixed handshake packet lengths and a predictable structure \u2014 it can be identified by a two-line rule, and honestly I have not seen a filter that could not handle it. And the permanent association of the key with an internal address means the server keeps more information about you by default than you might like. The second issue can be addressed by provider-side engineering. The first cannot be fixed inside the protocol itself.<\/p>\n

Well, it can be addressed \u2014 but outside the protocol. There are modifications that break the recognizable packet profile: junk data before the handshake, random sizes and altered header bytes. How that works and how much it helps is covered in the WireGuard obfuscation article<\/a>.<\/p>\n

[Image: timeline of VPN protocols from PPTP to modern protocols]<\/em><\/p>\n

VLESS, XTLS and Reality: An Answer to Deep Traffic Inspection<\/h2>\n

This is where the paradigm changes, and I do not think that is an exaggeration.<\/p>\n

All previous protocols solved one problem: securely connect two points. The problem of making the connection unobtrusive was not part of their design. VLESS grew out of an environment where that problem is central.<\/p>\n

VLESS itself is deliberately simple: it does not encrypt. At all. Encryption is delegated entirely to the transport layer, namely TLS \u2014 the same TLS that protects your banking app. Authentication is by identifier, one line, no passwords. No double encryption, no time-synchronization check that caused mysterious disconnects in its predecessor. I initially thought this simplification was a step backward and argued about it with colleagues. I eventually stopped.<\/p>\n

XTLS-Vision addresses the TLS-inside-TLS problem. When an encrypted stream is wrapped in another encrypted layer, a characteristic fingerprint appears in packet-size ratios and timings. XTLS passes already encrypted data without a second pass and masks the signature of the first packets.<\/p>\n

Reality is the most interesting part, and I could talk about it for a long time. The usual scheme requires your own domain and certificate, and both give you away: the domain is two weeks old, there is no traffic on it, and a browser request finds no real site there. Reality does not create its own domain at all. During the handshake, the server presents the certificate of a real third-party site \u2014 large, popular and known to be allowed. An outside observer sees a normal connection to a known resource. If it probes the connection, it sees a working site because the request genuinely reaches it. The difference from obfuscation is fundamental: obfuscation makes traffic unlike anything else, while Reality makes it resemble a specific allowed thing. The first helps against \u201cblock identified VPN traffic\u201d; the second can also survive allowlists.<\/p>\n

Among VPN protocols currently working in Russia, this is the most resilient option. Whether that remains true a year from now, nobody knows, including me: the armor-and-projectile race has never really ended. Technical details are on the VLESS page<\/a>; practical blocking notes are on the RKN blocking bypass page<\/a>.<\/p>\n

Hysteria2 and QUIC: Protocols for Links That Keep Breaking<\/h2>\n

The final branch of this evolution is about a completely different pain point.<\/p>\n

QUIC was not invented to bypass blocks; it was designed to fix an old TCP problem: when one packet is lost, the whole queue behind it waits for retransmission. On a wired connection that is rare; on a radio link it is normal. QUIC runs over UDP and splits the flow into independent parts, so a loss in one does not stop the others.<\/p>\n

Hysteria2 is built on QUIC and adds its own congestion control: it does not reduce speed after every loss but tries to hold the configured bandwidth, and on noisy mobile networks the difference is significant \u2014 where a TCP tunnel drops to \u201cmight as well turn it off,\u201d this one keeps going.<\/p>\n

The price, as I warned at the beginning, is visibility. A dense UDP stream on a nonstandard port that reacts to loss differently from everything around it stands out statistically. Operators also regularly restrict or deprioritize UDP, in which case the protocol simply does not come up. What to do about that is covered in the Hysteria2 vs VLESS comparison<\/a>.<\/p>\n

And since Shadowsocks keeps appearing nearby, let us mention it here too. Technically it is not a VPN but an encrypted proxy, and this confusion generates plenty of support requests: it forwards only traffic that an application sends to it, while system services and DNS bypass it. Why that happens and when it still makes sense is covered in the Shadowsocks article<\/a>.<\/p>\n

Summary Table: What, Where and Why<\/h2>\n

VPN protocols in 2026, all in one place. These are qualitative assessments: numbers depend on the link, hardware and provider, and I do not take percentages seriously without a described test setup.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Protocol<\/th>\nTransport<\/th>\nEncryption<\/th>\nSpeed<\/th>\nResistance to blocking<\/th>\nWhere to use<\/th>\n<\/tr>\n<\/thead>\n
PPTP<\/td>\nTCP + control channel<\/td>\nObsolete, breakable<\/td>\nHigh<\/td>\nLow<\/td>\nNowhere<\/td>\n<\/tr>\n
L2TP\/IPsec<\/td>\nUDP, fixed ports<\/td>\nReliable, but double encapsulation<\/td>\nMedium<\/td>\nVery low<\/td>\nLegacy corporate networks<\/td>\n<\/tr>\n
IKEv2\/IPsec<\/td>\nUDP, known ports<\/td>\nModern<\/td>\nHigh<\/td>\nLow<\/td>\nMobile devices without filtering<\/td>\n<\/tr>\n
SSTP<\/td>\nTCP, port 443<\/td>\nTLS<\/td>\nMedium<\/td>\nLow\u2013medium<\/td>\nWindows infrastructure<\/td>\n<\/tr>\n
OpenVPN<\/td>\nTCP or UDP, any port<\/td>\nHighly configurable<\/td>\nMedium<\/td>\nMedium over TCP\/443<\/td>\nCompatibility, corporate control<\/td>\n<\/tr>\n
WireGuard<\/td>\nUDP only<\/td>\nFixed modern suite<\/td>\nMaximum<\/td>\nLow<\/td>\nSpeed where UDP is not filtered<\/td>\n<\/tr>\n
WireGuard with obfuscation<\/td>\nUDP with noise<\/td>\nSame as WireGuard<\/td>\nHigh<\/td>\nMedium\u2013high<\/td>\nSignature-based filtering<\/td>\n<\/tr>\n
Shadowsocks<\/td>\nTCP, any port<\/td>\nModern, proxy-level<\/td>\nHigh<\/td>\nMedium, low without plugin<\/td>\nPoint access to sites<\/td>\n<\/tr>\n
VLESS + XTLS-Reality<\/td>\nTCP, port 443<\/td>\nVia TLS<\/td>\nHigh<\/td>\nVery high<\/td>\nStrict filtering, allowlists<\/td>\n<\/tr>\n
Hysteria2 (QUIC)<\/td>\nUDP<\/td>\nVia TLS in QUIC<\/td>\nVery high on lossy links<\/td>\nMedium, drops if UDP is blocked<\/td>\nMobile Internet, poor links<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n

[Image: decision tree showing which protocol fits which task]<\/em><\/p>\n

How to use this. It is more useful to divide VPN protocol types by the problem they solve than by age \u2014 that is how I finally organized them in my own head.<\/p>\n