What Makes a VPN Resistant to Censorship?
Censorship resistance is a property of six layers, from the bytes on the wire to the cloud provider, the CDN, and the response to a probe. Protocol is one of them.
Ask what makes a VPN resistant to censorship and the answer that comes back first is a protocol name. That answer is half right, and the half it misses is the half that decides most outages.
A protocol determines what your traffic looks like on the wire. It does not determine which address your server lives at, which network that address belongs to, what your server does when a stranger connects to it, or whether the app store still distributes the client. Those are separate layers, they fail separately, and the documented record shows that layers below the protocol decide more failures than the protocol does.
Short answer#
Resistance to censorship is a property of a stack of choices, not of a single component. Six layers, in the order they are usually considered:
- Protocol — what the bytes look like
- Address — which IPs, how many, how fast they change
- Provider — whose network those IPs sit in, and what that provider’s incentives are
- Placement — whether blocking you means blocking something else the censor needs
- Probing — what your server does when an unauthorised client connects
- Operations — how the stack is tested, rotated and maintained
Most discussions stop at layer one. The evidence below is about why that is not enough.
The protocol layer#
This is the layer people mean when they ask the question, so it is worth stating plainly what it does and does not buy.
A protocol determines the shape, timing and handshake of your traffic. Obfuscation vs encryption separates the two properties that get conflated here: encryption makes the contents unreadable, and obfuscation makes the traffic harder to classify. The three strategies for the second property (mimicry, look-like-nothing, and borrowing a real site’s identity) have sharply different track records, and that article covers them in detail.
The short version is that the protocol layer can be defeated by measurement alone. A study published in Communications of the ACM fingerprinted OpenVPN from an adversarial internet provider position and identified over 85% of flows. The result that matters for this article concerns the obfuscated variants: the same framework still identified 34 of 41 commercial configurations sold as obfuscated, and the authors found that most of those implementations resembled OpenVPN with a simple XOR patch applied.
WireGuard is the cleanest illustration of the layer’s limits. It is a well-audited protocol with a small code surface and no cipher agility, and its wire appearance is WireGuard on UDP, unchanging, with no mechanism to vary that. On an unrestricted network that is a strength. On a network that filters tunnels it is a signature, and better cryptography does nothing about it.
AmneziaWG, announced in October 2023, exists because of exactly this. It is a WireGuard fork that adds configurable randomisation to packet fields so that the habitual DPI signatures which had come to match WireGuard stop matching. The design is a direct response to the August 2023 Russian blocking of WireGuard, and it demonstrates the layer’s proper role: it changes what the traffic looks like, and it changes nothing about where the server is or who hosts it.
The address layer#
The Tor Project’s Snowflake states its own source of resistance more directly than any external description does: its blocking resistance comes from the use of numerous, ultra-light, temporary proxies, and the large and changing pool of proxy addresses resists enumeration and blocking by a censor. The system is designed with the assumption that proxies may appear or disappear at any time, and when an in-use proxy goes offline, its client switches to another invisibly to upper network layers.
Snowflake’s proxies run on volunteer residential machines, which is why its address pool is both large and hard to enumerate. A VPN server is not in that position: it is a deliberately provisioned machine at a deliberately chosen address, and that address is a single point of failure at the transport layer.
The Georgetown work on ephemeral exit bridges makes the complementary argument for fixed addresses. Its authors observe that bridges with fixed IPs will likely eventually be exposed and adversaries can block such bridges just as they block Tor exit relays, and their design answer is that exit bridges should have a wide IP range, such that if the adversaries decide to block the whole range, they will suffer substantial collateral damage.
That second clause is the important one. An address pool that is small and static is a list. An address pool that is wide and shifting is a cost, because blocking all of it means blocking a great deal of legitimate traffic along the way.
The trade-off is real: a large rotating pool is harder to operate, harder to support users on, and harder to keep fast. The design question for any given VPN is not whether rotation is good in the abstract, but how much address diversity its threat model can afford and how quickly it can replace an address that has been enumerated.
The provider layer#
This is the layer that protocol-focused discussion skips, and the record shows it deciding outages.
Large VPN providers run many servers, and those servers live on well-known datacenter ranges. A project maintained by rezmoss publishes daily-updated IP datasets for 67 providers in firewall-ready formats; as of October 2026 it tracked 466,394 CIDRs covering 460 million IPv4 addresses, roughly a tenth of the IPv4 space. The dataset exists because network operators want to allowlist and denylist cloud traffic, and the same lists serve a censor perfectly well.
The ASNs behind the mainstream hosting providers are a short list, and they are not secret. M247, DigitalOcean, Hetzner, OVHcloud, Linode and Vultr appear repeatedly in analyses of VPN infrastructure, and a censor that maintains blocklists of those ranges can shut down access to a great many services in one move, along with every ordinary website that happens to share the range.
Iran’s filtering apparatus shows what this looks like at national scale. The IRBlock study, presented at USENIX Security 2025, measured the entire Iranian IP address space over 2.5 months and tested more than 500 million apex domains. It identified 6.8 million addresses subject to DNS poisoning and HTTP blockpage injection, and 5.4 million subject to UDP disruption. It also found blanket blocking of entire top-level domains, which caused large collateral damage to innocuous websites. The apparatus operates at the level of address space, not at the level of individual servers.
The Russian record from 2026 is the most recent and most explicit instance. Human Rights Watch reported that the waves of blocking that year targeted VPN services’ infrastructure directly: large blocks of IP addresses, including entire subnets allocated to them by their hosting providers. A representative of an affected service told the organisation that restoring access after such bulk blocking takes longer and costs more than the earlier, more granular address blocking. When a censor moves from blocking an address to blocking the range an address lives in, the cost of renting somebody else’s network rises sharply.
This is why provider selection is a censorship-resistance decision rather than a procurement convenience. A provider whose ranges already appear on well-known blocklists, or whose ASN is heavily associated with VPN traffic, transfers that association to every tenant.
The placement layer#
The idea is old and the name for it is collateral freedom: arrange matters so that blocking your server means blocking something the censor needs.
Domain fronting was the sharpest implementation. A request carried one domain in the TLS SNI field, visible to the censor, and another in the HTTPS Host header, invisible under encryption. The CDN routed on the inner name. The Signal Foundation described the resulting dilemma: to block one domain-fronted site you have to block the rest of the internet as well.
It worked for years. It was then closed by the providers, on their own schedule, in a sequence worth reading as a caution about the layer’s durability:
- Cloudflare had disabled domain fronting since 2015.
- On 14 April 2018, Google blocked it in its cloud.
- On 27 April 2018, Amazon announced it was blocking it.
- In March 2021, Microsoft announced an intention to ban it in Azure.
The Russian Telegram block of April 2018 supplies the other half of the story. Telegram fronted through Google and Amazon CDNs; the censor responded by blacklisting millions of IP addresses belonging to Google and Amazon, and Hetzner space was caught in the same sweep. The collateral damage was immediate (banks, retail chains and unrelated websites went down), and the block did not stop Telegram. It did, however, create the conditions under which the cloud providers chose to remove fronting from their platforms.
Psiphon’s Michael Hull, asked about the technique at the time, was blunt with CyberScoop: domain fronting on its own is not very effective, it has to be combined with obfuscation, HTTP header modification and transport fragmentation to defeat a sophisticated censor, and the importance of a diversified circumvention toolbox cannot be overstated. He also observed that the technique breaks the CDN design, which explains why the CDNs stopped tolerating it.
The layer’s lesson is therefore a mixed one. When it works, it is the strongest form of resistance available, because the cost of blocking falls on infrastructure the censor cannot afford to break. When it stops working, it stops working because of a business decision taken in California, and no amount of protocol engineering on your side reverses it.
Variants survive: domain hiding, which passes an encrypted request for one resource behind a plaintext request for another in the same cloud, and refraction networking, which applies the same principle at the network layer rather than the application one. The principle is durable even where the specific technique is not.
The probing layer#
Active probing is the technique where the censor, having noticed a connection, connects to the server itself and asks it what it is. It changes the character of the problem: the server is no longer passively recognisable, it is being interviewed.
The failure mode is straightforward. A prober sends a hand-crafted packet, and a server that responds as a VPN server has confirmed the classification and given the censor an address to block. The design answers are covered in what REALITY is and in the obfuscation article, and they share a structure: the server must not answer as itself.
The borrowed-identity strategy is the one that survives probing, because the response is real rather than simulated. REALITY has Xray pass unauthorised traffic to a target site, so a probe receives a genuine certificate issued by a genuine authority for the site it asked for. Cloak serves a fronted HTTPS site to anyone who is not authenticated. In both cases the server’s answer to a stranger is indistinguishable from its answer to a legitimate visitor of the borrowed site.
The cost side of this layer deserves stating. Borrowing an identity means the server now depends on the borrowed site’s behaviour and address range. If the target site changes its TLS configuration, or is itself blocked, or begins answering probes differently, the camouflage degrades without any change on your side. This is the probing layer’s version of the provider layer’s lesson: resistance that depends on a third party’s behaviour has a schedule set by that party.
The operational layer#
Everything above is a static property of a configuration. Whether that configuration still works on a given network on a given Tuesday is a property of how it is run.
The Russian data shows why. When OpenVPN and WireGuard were blocked in August 2023, at least 6 of 15 popular services lost access, and the study that reported the figure also found that 6 of those 15 had a built-in ability to use obfuscators that few users knew about. The gap between having a defence and having it enabled is an operational failure, not a technical one.
The same study identified a user-side pattern worth naming: the strategy of trying different VPN services in search of a working one, which it described as a major vulnerability when popular protocols get blocked. Each attempt is a connection to a new address, from the same client, with the same observable behaviour. The churn is visible.
The operational layer therefore covers the things that no protocol specification can:
- Testing against networks where filtering is active, rather than assuming an open route behaves like a restricted one.
- Rotating addresses on a schedule, rather than waiting for an address to be enumerated and blocked.
- Keeping more than one transport available, so a single signature does not take the whole service down.
- Monitoring reachability from outside, so failure is detected by the operator and not only by the user.
- Keeping the obfuscation options enabled by default, since a defence that is present but off is a defence that does not exist.
This is also the argument behind infrastructure selection. Maronix’s rule is simple: know the machine, not just its address. The project’s engineers keep root on every box and study each provider’s hardware and network first-hand. No server is trusted with traffic until the team has audited it and it has survived attacks deliberately run against Maronix’s own systems.
What the layers look like together#
| Layer | What it defends against | What it does not address |
|---|---|---|
| Protocol | Classification by traffic shape and handshake | Address enumeration, provider blocklists, probing |
| Address | Enumeration of a fixed server list | Blocks on the range an address sits in |
| Provider | ASN and subnet-level blocking | Protocol signatures, probing |
| Placement | Blocks that would require collateral damage | Provider policy changes; the borrowed site’s behaviour |
| Probing | Active confirmation of what a server is | Volume and duration of traffic; the server’s real address |
| Operations | Drift between a working configuration and a working network | Anything that has not been tested |
No single row is sufficient. The rows are also not independent: a strong protocol on a blocklisted subnet fails at layer three, and a rotating address pool with a probe-answering server fails at layer five. The useful question about any given stack is which row is the thinnest, because that is the row that will fail first.
Common misconceptions#
“The newest protocol is the most censorship-resistant one.” WireGuard is newer than OpenVPN, simpler and better audited, and it was the protocol blocked in August 2023 because its wire appearance is itself a signature. Recency and resistance to classification are unrelated properties.
“Obfuscation makes a stack resistant to censorship.” It addresses one layer. A stack with excellent obfuscation on a Hetzner subnet that appears on a maintained blocklist is still unreachable, and no amount of traffic shaping changes that.
“A large server count means resilience.” A thousand servers on one provider’s ASN is one blocklist entry away from zero. Address diversity and provider diversity decide this, not the raw count.
“Domain fronting is the answer.” It was a strong answer for roughly three years, and it was removed by cloud providers acting on their own terms of service. The principle behind it survives; the specific technique does not.
“If it works today, the stack is sound.” It is sound against the environment you tested it in. Why a VPN can work today and fail tomorrow is about the four distinct ways that environment changes underneath a working tool.
Related#
- Obfuscation vs Encryption — the protocol layer, separated into its two independent axes
- What Is REALITY? — the borrowing-a-real-site strategy in detail
- Why Maronix Uses VLESS + REALITY — one stack’s answers across these layers
- What Should You Look for in a VPN? — the consumer-level version of the six-layer checklist
- Who Controls the Infrastructure? — the provider layer, from the ownership side
- Why a VPN Can Work Today and Fail Tomorrow — the failure record these layers are designed against
- What Is Internet Censorship? — the five-layer filtering model these six answer
- What Is Hysteria2? — one protocol’s answer at the transport and protocol layers
Sources
- Snowflake, a censorship circumvention system using temporary WebRTC proxies (USENIX Security 2024) USENIX
- Ephemeral Exit Bridges for Tor (DSN 2020) Georgetown University
- Cloud Provider IP Addresses (daily-updated CIDR datasets) rezmoss
- IRBlock: A Large-Scale Measurement Study of the Great Firewall of Iran (USENIX Security 2025) USENIX
- Russia Crackdown on Bypassing Online Censorship Human Rights Watch
- Domain fronting Wikipedia
- Domain fronting has a dwindling future CyberScoop
- Behind the curtain: Russia's internet censorship in 2026 Mediazona
- VPN in Russia: from blocking services to blocking protocols Roskomsvoboda
Last reviewed October 30, 2026. This article was revised after publication. Corrections and additions are welcome.