An internet shutdown is the removal of connectivity itself, not just the blocking of specific sites. Governments order them through legal or emergency powers, but under international human rights law blanket shutdowns are almost always disproportionate. During a full shutdown, no client-side VPN can restore international connectivity because the network paths have been withdrawn.

Shutdowns vs censorship vs throttling#

These are different tools with different legal and technical effects:

Legal justifications#

Governments that order shutdowns almost always point to one of the following justifications:

• Public order - To prevent coordination during protests or unrest.
• National security / armed conflict - Often used during wars or periods of heightened tension.
• Elections - To limit coordination or the spread of information during voting periods.
• Communal violence / misinformation - To prevent incitement or the spread of unverified content.

The key question is not whether a government can declare a concern, but whether the response is necessary and proportionate. A blanket cutoff of an entire population is rarely proportionate to a specific threat.

International law: necessity and proportionality#

Several sources make this clear:

• ICCPR Article 19 - Protects freedom of expression and the right to seek, receive and impart information. Access to the internet is central to exercising this right in the modern era.
• The Siracusa Principles - Clarify that any limitation on rights must be prescribed by law, serve a legitimate purpose, be necessary, and be proportionate. Vague “national security” claims cannot justify indiscriminate measures.
• UN Special Rapporteurs on Freedom of Expression - Have repeatedly condemned blanket internet shutdowns as disproportionate and in violation of international human rights obligations. The Joint Declarations on freedom of expression have also warned against shutdowns.
• OHCHR statements - Have consistently raised concerns about shutdowns, noting their impact on emergency services, journalism, healthcare, and democratic processes.

In short: targeted measures may be considered in narrow circumstances, but blanket, nationwide shutdowns are almost never justifiable under these standards.

Examples from recent years#

Accountability and transparency#

Shutdowns suffer from a persistent accountability gap:

• Vague orders. Many are issued verbally or through opaque channels with no public justification.
• Lack of judicial oversight. Orders are often made by executive bodies with little or no prior review.
• No ex post review. Even when challenged, courts often rule after the shutdown has ended or refuse to hold those responsible accountable.
• Impunity. There are few documented cases where officials have been held accountable for an unlawful blanket shutdown.
• Data gaps. As noted in How Often Do Countries Shut Down the Internet?, tracking relies on observation and reporting, so the true number is almost certainly higher than documented.

Impact on users#

• Emergency services - Shutdowns cut access to medical information, hotlines, and coordination during crises.
• Journalism - Reporters cannot send footage or reports out, and citizens cannot document abuses.
• Economy - Businesses that rely on online payments, communication, or delivery suffer immediate losses.
• Education - Online classes become inaccessible.
• Circumvention fails - During a full shutdown, VPNs, proxies, and obfuscated protocols cannot create an international path. If only the domestic network remains (like Iran’s NIN), domestic services may work but global ones won’t. Starlink can be jammed, illegal, and risky to use.
• Chilling effect - Even short shutdowns create fear and disrupt coordination long after restoration.

Practical considerations#

• Plan ahead. If you’re in a region at risk of shutdowns, download maps, documents, and configurations offline. Agree on alternative communication plans in advance.
• Know the difference. Test whether domestic sites load while international ones don’t. If domestic sites work, the NIN or local network may be up even if the global internet is down.
• Expect restoration to be partial. As seen in Iran, access can return with throttling, filtering, and tiered access. Throughput may be poor even when connections are technically possible.
• No miracle tool. There is no client-side setting that restores a withdrawn international route. Focus on preparation, not last-minute downloads.
• Legal awareness. In some jurisdictions, using certain tools during a shutdown may carry additional risk. This page describes network and legal trends, not legal advice.

Atlas articles#

• How Often Do Countries Shut Down the Internet? - The data on frequency and trends
• What Is Internet Censorship? - How filtering differs from shutdowns
• Internet Censorship in Iran - A concrete example of prolonged shutdowns and restoration
• VPN Bans and Regulation: What the Law Actually Does - The legal pressure that often accompanies shutdowns
• Why a VPN Can Work Today and Fail Tomorrow - Why shutdowns break tunnels differently

Most governments do not “ban VPNs” for every citizen in the sense of writing a law that says “using a VPN is a crime for everyone”. More often, they use regulation to make providing VPNs harder, force compliance with blacklists, pressure app stores to remove clients, or create legal risk for providers and users. The law creates pressure; the network does the blocking.

Bans vs regulation vs pressure#

These terms get conflated. The distinction matters because it determines where the failure happens:

In practice, these stack. A law creates an obligation; non-compliant providers get blocked; app stores remove them; and ISPs use technical measures to catch what remains.

How the law becomes technical#

Laws rarely say “drop all WireGuard traffic”. They say “block access to banned resources” or “comply with the unified register of blocked sites”. The technical implementation follows:

• Obligations become blocklists. If a provider refuses to comply with demands to block certain sites or to restrict access, regulators can order ISPs to block the provider’s infrastructure. This is the mechanism used in Russia under its 2017 law.
• Inspection systems enforce at scale. Russia’s TSPU sits inside carrier networks and can apply blocks to addresses, subnets, and protocols. Iran uses gateway controls and whitelisting to restrict international access. China’s system combines legal requirements, carrier policy, and border filtering.
• Pressure moves upstream. Hosting providers, CDNs, and app stores are not neutral pipes. Legal pressure can result in suspended services, removed apps, or blocked payments even if the underlying protocol is sound.

This is why a VPN can work one week and fail the next: the legal pressure changes, and technical enforcement follows.

Case studies#

Russia#

Russia’s 2017 law requires VPN services to block access to resources on the state registry or face blocking. Since then, Roskomsvoboda has documented a shift from blocking specific services to blocking entire protocols and subnets. Enforcement waves have targeted both providers and, increasingly, the infrastructure that hosts them. App store removals and payment friction have also played a role. The result is not a total ban on VPN use, but sustained pressure that makes reliable access harder to maintain.

Iran#

Iran takes a different approach: tiered access. Approved users on “white SIMs” or Internet Pro can reach international gateways with less restriction, while the general population faces filtering and shutdowns. Proposed legislation has repeatedly sought to tighten control over gateways and require authentication. VPN use is not broadly criminalized in the current draft, but legal uncertainty remains and enforcement can be unpredictable. The key point: regulation enables whitelisting, which creates a two-tier system rather than just blocking tunnels.

China#

China does not have a blanket criminal ban on using a VPN as a private individual in most cases, but unapproved VPN services are blocked and providers face pressure. App stores have removed VPN apps at government request. Carriers conduct sweeps to block VPN traffic, and distribution is heavily constrained. The legal environment is opaque, but the effect is clear: obtaining and maintaining a working client is the hard part, and approved enterprise VPNs exist in parallel.

Turkey#

Turkey has a history of blocking orders against VPN services and periodic restrictions during periods of tension. Courts can order blocks, and providers are often caught between compliance demands and user access. This demonstrates how judicial orders can be used to restrict circumvention without a permanent, country-wide criminal ban on all VPN usage.

Consequences for users and providers#

Important: This article describes legal and technical trends, not legal advice. Laws change frequently and enforcement varies. If you need legal advice for a specific situation, consult a qualified lawyer in your jurisdiction.

What the law doesn’t do#

• It doesn’t make all VPNs undetectable. Regulation can make them unavailable even if the protocol is strong.
• It doesn’t require universal criminalization to be effective. Blocking obligations and app store pressure can be more effective than prosecuting millions of users.
• It doesn’t fix the technical problem. A law can force compliance, but DPI and active probing still exist. Conversely, strong protocols can’t overcome a complete shutdown or a total block of all possible exit paths.
• It doesn’t create a single global pattern. Approaches differ wildly. Some focus on providers, some on gateways, some on platforms.

Practical considerations#

• Know the mechanism. If a client disappears from the app store, that’s likely regulatory/app store pressure, not a technical bug. If all servers fail at once, it’s likely blocking or a sweep.
• Assume availability is fragile. Download and save configurations offline before you need them, especially when traveling to or through restrictive jurisdictions.
• Understand the split. The question isn’t “is VPN use banned?” but “is it easy or risky to provide, distribute, and maintain access right now?”
• Treat risk separately. Technical resistance and legal risk are different. Strong protocols help with detection, but they don’t remove legal exposure in places where use is restricted or risky.
• Stay informed. Follow reputable sources like Access Now, EFF, OONI, and local digital rights groups for changes in enforcement, not just laws on paper.

Atlas articles#

• Internet Censorship in Russia - How TSPU and enforcement waves work in practice
• Internet Censorship in Iran - Whitelisting, tiered access, and gateway control
• Internet Censorship in China - Carrier sweeps, app store pressure, and the Great Firewall
• What Makes a VPN Resistant to Censorship? - Protocols, addresses, and operations
• Why a VPN Can Work Today and Fail Tomorrow - How blocks evolve
• Commercial VPN vs Independent VPN - Tradeoffs in resilience and pressure

Most domestic traffic stays inside the country and does not cross the national filter. Cross-border traffic does. That distinction explains why a site can load normally inside China and fail when the same request leaves the country, and why a working tunnel changes the path rather than the destination.

The system is also uneven. A provincial network can filter more aggressively than the national firewall. A mobile carrier can block a protocol that works on a fixed line. A service can survive a DNS block and still fail at the TLS handshake. The useful question is which layer is stopping the connection.

Current situation#

The national filtering apparatus is distributed across international gateways operated by the large state carriers. It combines DNS poisoning, IP address blocking, TLS server name filtering, QUIC inspection, active probing and traffic classification. These systems do not share one blocklist or one decision. Research has repeatedly found separate rules for different protocols and middleboxes.

The baseline has been stable for years. A blocked domain can resolve to a forged address, a blocked address can be dropped, and a blocked TLS hostname can trigger a connection reset. What changes is the mix. Since April 2024, the firewall has also inspected QUIC Initial packets and blocked specific domains carried over HTTP/3. In August 2025, a 74-minute incident injected resets into all TCP port 443 traffic, showing that port-level blocking is available even when it is not the normal policy.

Filtering is not only national. A 2025 measurement study documented a provincial firewall in Henan that inspected outbound TLS server names and HTTP Host headers. At times it blocked ten times more second-level domains than the national firewall. The authors found no comparable system in six other provinces they measured, but the case shows that local networks can add their own layer.

The legal environment sits around the network. The state permits approved VPNs, mainly for enterprises, and these are easier to monitor. Unapproved services are blocked, and their operators and distributors face enforcement. That is separate from whether a particular tunnel works at a given moment.

Known techniques#

DNS poisoning is the cheapest layer. The resolver returns an address that does not belong to the requested site, or returns nothing. Encrypted DNS can avoid a poisoned local resolver, but it does not hide the destination from the next layer. A tunnel that resolves names remotely also moves the lookup, yet the TLS handshake to the tunnel endpoint still exposes an address and often a hostname.

TLS filtering is the layer most users meet without seeing it. The ClientHello carries the server name in cleartext unless Encrypted Client Hello is in use, and ECH is not a reliable assumption on Chinese networks. A middlebox can read the name, compare it with a list and send a reset before any content arrives. The result looks like a server failure rather than a block.

QUIC adds a newer path. QUIC encrypts its payload, but the first packet is encrypted with a key that an on-path observer can derive. The firewall decrypts that packet at scale, reads the server name and applies a separate blocklist. The 2025 study found the decryption cost reduces effectiveness under load, but the capability is real and has been integrated into blocking since 2024.

Address blocking remains the simplest and most durable layer. A server on a known range can be dropped without inspecting anything. The August 2025 port 443 incident was a different form: resets were injected for all TCP traffic to that port, regardless of destination. It lasted about 74 minutes and did not match known firewall fingerprints, which suggests a new device or a misconfigured one. The episode is a reminder that a non-standard port is not a security boundary.

Active probing targets the server rather than the user. The firewall connects to a suspected proxy and watches how it responds. A server that accepts any TLS client, or that answers differently from the site it claims to be, is easier to identify. This is why probe resistance is a server-side property, not a client setting.

Traffic classification handles tunnels that do not look like TLS. The 2020 Shadowsocks study showed that a classifier can identify the protocol from packet length, timing and entropy even without reading the payload. The practical consequence is that a new obfuscation layer only helps until the classifier is retrained. Protocol diversity and operational churn matter as much as the cipher.

Recent events#

31 January 2026. The Ministry of Public Security published a 68-article draft Law on Cybercrime Prevention and Control. Human Rights Watch said it would consolidate telecom, internet and banking rules, add dynamic real-name verification and expand the grounds for suspending accounts and communication services. The text reviewed here is a draft, not an enacted law.

April 2026. Censorship analyst Eric Liu told ABC News that telecom carriers in parts of China were asked to comb through their networks and block VPN services. LetsVPN, a provider popular with expatriates, suspended service in mainland China and cited continuous internet blocking. It resumed in May but said it could not guarantee availability. Users described having to switch providers as stable services became harder to find.

27 May 2026. The Global Public Policy Institute published an analysis of documents leaked from Geedge Networks, a Chinese traffic-management contractor. The documents describe per-carrier reporting on foreign app use in Xinjiang, including weekly traffic summaries. GPPI found that foreign traffic averaged just over 4% of total traffic in the reports and cautioned that the region is not an ideal representative sample for all of China. The analysis is evidence of how filtering and surveillance share carrier data, not a measurement of nationwide VPN use.

6 August 2026. The Ministry of Public Security issued Order No. 176 on cyberspace security inspection. It took effect on 1 October and replaced the 2018 rules. Police at prefecture level and above can conduct remote technical testing, including vulnerability probing and penetration testing, against network facilities outside critical information infrastructure, with three working days’ notice. Inspections cover log retention, content controls, algorithm governance, data protection and cooperation with criminal investigations.

The order is not a new border filter. It is an inspection regime. Its relevance to circumvention is indirect: it expands police access to the networks, records and operators that host or carry tunnel infrastructure, and it makes compliance checks more frequent for some providers.

The public record for late 2026 does not show a new nationwide filtering architecture. The direction is tighter enforcement, more carrier-level scanning and more legal pressure around the existing system.

Effects on users#

The first effect is reliability. A tunnel that works on one carrier can fail on another, and a service that works in one province can fail in Henan. A blocked address can be replaced, but a carrier-level sweep can remove many endpoints at once. Users see reconnects, changed server locations and periods when no provider works consistently.

The second is protocol drift. DNS tricks handle poisoned names, but not an SNI reset. A TLS-camouflaged tunnel can pass an SNI filter, but a server that answers probes incorrectly is still discoverable. QUIC-based tools can avoid TCP resets and then run into QUIC inspection or UDP throttling. Each fix moves the problem to another layer.

The third is installation. Service suspensions, account checks and distribution pressure make it harder to obtain a client after a block is announced. A client installed before travel, with configurations saved offline, is more useful than a download link that depends on the same network being filtered.

The fourth is legal and organisational risk. Approved enterprise VPNs remain available, but unapproved services operate outside the licensing regime. The technical question of whether a tunnel works is separate from the legal question of whether a person or organisation may use it.

The fifth is visibility. Most traffic never leaves the country, and domestic platforms are often faster and more useful than blocked foreign ones. A user can have a working tunnel and still choose domestic services for most tasks. That is a design outcome, not a failure of the tunnel.

Relevant protocols#

WireGuard and OpenVPN are poor defaults against this system. WireGuard has a fixed handshake and a recognisable packet format. OpenVPN has more configuration options, but common profiles are well known to classifiers. Obfuscation can change the signature, but it does not change the server address or the traffic pattern.

Shadowsocks improves on the old proxy protocols, but the 2020 measurement work showed that its traffic can be separated from ordinary TLS by statistical features. A newer variant or plugin may work for a period. It should not be treated as invisible.

VLESS inside REALITY addresses two specific layers. VLESS adds no inner TLS session for a filter to classify, and REALITY borrows the handshake of a real site so that a probe receives a genuine certificate. That helps with SNI filtering and with naive active probing. It does not hide the endpoint address, the volume of traffic or the behaviour of the destination.

Hysteria2 runs over QUIC and can perform well on lossy mobile links. It is also exposed to QUIC inspection and to networks that throttle or block UDP. A deployment that depends on one transport has one failure mode.

The practical lesson is that protocol choice is one variable. Address diversity, hosting provider, probe response, port choice and operational testing decide whether a configuration stays reachable. A strong protocol on a blocked address is still blocked.

Maronix keeps improving its server configuration and setup against these findings, testing deployments on restricted networks and changing the details that stop working instead of treating one reachable setup as permanent.

Practical considerations#

• Install the client and save configurations before you travel. App-store access and account recovery can fail on the network you are trying to cross.
• Test fixed and mobile connections separately. Carriers can apply different rules, and a tunnel that works on Wi-Fi may fail on mobile data.
• Keep more than one transport and more than one endpoint. A single address or a single port is a single blocklist entry.
• Test the services you actually use, not just the tunnel handshake. A connection can open and still fail against a platform that blocks the destination or rejects the tunnel.
• Do not assume a domestic Wi-Fi network is unfiltered. All major carriers connect to the same border system, and provincial networks can add rules.
• Treat legal risk as separate from technical risk. Approved business connectivity is a different product from an unapproved consumer tunnel. This page describes network behaviour, not legal advice.
• Expect variation by province, carrier and date. A configuration that works this week can fail after a carrier sweep or a rule change, and the reason may be an address, a handshake or a port rather than the protocol.

Atlas articles#

• What Is Internet Censorship? - the five layers behind the Great Firewall
• What Is Deep Packet Inspection? - how middleboxes classify encrypted traffic
• Why a VPN Can Work Today and Fail Tomorrow - the difference between an address block, a protocol block and a probe
• What Makes a VPN Resistant to Censorship? - protocol, address, provider, placement, probing and operations
• What Is VLESS? - the proxy core used inside REALITY
• What Is REALITY? - borrowed handshakes and probe resistance
• What Is Hysteria2? - QUIC transport and its trade-offs

The system is more centralized than Russia’s. The state-linked carriers and international gateways are the main chokepoints, while the National Information Network (NIN) keeps domestic services running during a cutoff. Around that core, Iran layers DNS poisoning, hostname filtering, protocol whitelisting, traffic shaping and a tiered access model that gives approved users a cleaner path.

The useful question is still which layer is stopping the connection. A shutdown, a DNS lie, a TLS reset, a UDP restriction and a slow path all look like “the internet is down” to a user. They require different responses.

Current situation#

Iran’s filtering is built around central gateways and a domestic network. The National Information Network (NIN) is a separate domestic network that keeps local banking, government services and many domestic platforms reachable even when international connectivity is cut. When authorities order a shutdown, international traffic can fall to near zero while the NIN remains available. During the 88-day shutdown that began on 28 February, VOA reported that NetBlocks measured national connectivity at roughly 1% of pre-war levels.

The first near-total shutdown began on 8 January during nationwide protests and lasted about three weeks. Service returned unevenly before a second cutoff began on 28 February after US and Israeli strikes. That second shutdown lasted 88 days, or more than 2,000 hours. It was the longest nationwide internet shutdown recorded at the time.

Restoration began on 26 May, but it did not return the network to its pre-January state. Cloudflare measured traffic at 40% of pre-shutdown levels on 27 May. It later peaked near 90% before settling around 59%. FilterWatch argued that capacity figures overstated the recovery: users were connected, but per-device traffic was at its lowest level on record, with artificial latency, unstable TCP, severe UDP restrictions and widespread DNS tampering.

That pattern is the important technical shift. A shutdown is visible as a cliff. The current model is a partial reopening that preserves control through shaping and filtering. The connection exists, but it carries much less useful traffic, and only some destinations work.

A second layer is legal and commercial. The state permits a tiered service, sold as Internet Pro, that routes approved users through less restricted international gateways. It is gateway-based whitelisting tied to white SIM cards and a verification process, not a VPN. There is no user-configurable encryption or tunnel: approved accounts are exempted at the gateway level. The rest of the population faces the filtered path and a black market for tunnels.

Known techniques#

DNS poisoning is the oldest visible layer. Blocked names have historically resolved to 10.10.34.34, an address that serves a block page. A 2025 measurement study of Iran’s address space found 6.8 million IPs affected by DNS poisoning or HTTP blockpage injection and 5.4 million affected by UDP-based disruption. The same study found blanket blocking of entire top-level domains, which overblocked many unrelated sites. To test for DNS interference, check whether a domain resolves to 10.10.34.34 or a known block page rather than assuming a tunnel failure.

TLS filtering is the selective layer. The ClientHello carries the server name in cleartext unless Encrypted Client Hello is in use, and ECH is not a dependable assumption on a filtered network. A middlebox can read the name and reset the connection before content arrives. This is how specific platforms can fail while the rest of the internet remains reachable.

The protocol whitelist is a separate design. A 2020 USENIX study documented a filter that allowed DNS, HTTP and HTTPS while disrupting other protocols. The exact list changes, but the design has the same effect: a tunnel that does not look like an allowed protocol is easier to block than one that does.

UDP is the current weak point for many modern tools. FilterWatch’s June 2026 measurements found severe UDP restrictions and unstable TCP connections after the partial reopening. QUIC runs over UDP, and so do Hysteria2 and many real-time applications. A network that throttles UDP can leave TCP browsing working while making a QUIC-based tunnel unusable.

Traffic shaping is harder to notice than a block. Artificial latency and packet loss degrade a connection without producing a reset. The result is a tunnel that connects but cannot carry a video call or a large download. Official confirmation came on 13 October, when a government spokesperson said agencies sometimes reduce internet speed because of wartime conditions.

The tiered model is the newest layer. White SIM cards and Internet Pro route approved users through gateways with little or no filtering, while ordinary subscribers remain on the restricted path. This is not a technical bypass that anyone can configure. It is an access tier granted through an institution or an application process.

Satellite access sits outside the terrestrial path, and Iran treats it as a security problem. Al Jazeera reported in October that authorities use multiple jammers, spoofed GPS signals, protocol identification and physical patrols against Starlink terminals. Using or possessing a terminal carries a baseline sentence of six months to two years, with longer terms for import and distribution.

Recent events#

8 January 2026. A nationwide shutdown began during protests. Traffic fell to near zero, and the domestic network remained available for approved services. Service returned unevenly later in January before the second shutdown.

28 February 2026. A second, longer cutoff began after US and Israeli strikes. It lasted 88 days and more than 2,000 hours. Cloudflare and NetBlocks recorded near-total loss of international connectivity.

10 May 2026. CNN reported that Internet Pro and white SIM cards were providing a two-tier system. Approved users could reach the global internet through less restricted gateways while ordinary users remained filtered. The programme had been sold through MCI since February.

26 May 2026. Restoration began. Cloudflare measured traffic at 40% of pre-shutdown levels the next day, later peaking near 90% and settling around 59%. FilterWatch reported that actual international traffic was about 60% of the pre-January level by 28 May, with throttling and filtering still in place.

26 August 2026. A new draft Cyberspace Regulation Plan was presented to lawmakers. RFE/RL reported that it would give the Supreme Cyberspace Council control of internet gateways, require ISPs to authenticate users, require foreign platforms to have a physical presence in Iran, and allow fines or licence revocation. The draft omits the earlier bill’s criminalisation of VPN use, but it was not law as of this update.

13 October 2026. A government spokesperson confirmed that some agencies occasionally reduce internet speed, citing wartime conditions. The statement followed weeks of user reports about slow international connections.

14 October 2026. Al Jazeera reported that Iran was escalating its campaign against Starlink, including jamming, GPS spoofing and terminal seizures. Officials described satellite internet as a tool of war and signalled support for a wider tiered-access model.

23 October 2026. MCI and Irancell raised mobile internet, call and SMS tariffs by up to 40%. Irancell also raised fixed internet and fibre prices by the same amount. The increase took effect at midnight, and packages bought before the change keep their original prices until expiry.

Effects on users#

The first distinction is shutdown versus filtering. During a national shutdown, the international path is gone. A VPN, proxy or alternate protocol cannot create a route that the border does not carry. Domestic services on the NIN may still work, which makes the failure look selective rather than total. Test NIN vs global separately to tell them apart.

The second is the layer of filtering. A poisoned DNS answer can be bypassed with encrypted DNS or remote resolution, but the TLS handshake still exposes the destination. An SNI reset can be avoided with a camouflaged tunnel, but a protocol whitelist or UDP restriction can remove the transport. A tunnel that connects is not proof that the path is usable.

The third is throughput. Iran’s post-restoration network can accept connections while making them too slow for video, file transfer or many interactive services. A client may show “connected” while pages time out. Testing a speed test or a large download is more informative than checking the tunnel indicator. Reported percentages differ between sources because some measure capacity while others measure actual per-device traffic.

The fourth is tiered access. A white SIM or Internet Pro account can reach international services that an ordinary SIM cannot. This is gateway-based whitelisting, not a user-configurable VPN. It creates a false impression that the network is working normally for everyone. A configuration that works for one person may fail for another on the same street because the access tier is different.

The fifth is platform-side blocking. Even without a wholesale shutdown, specific platforms can be blocked or disrupted via DNS, SNI or IP filtering. A working tunnel may still fail against a service that refuses VPN traffic or behaves differently, or the platform itself may be filtered on the domestic path.

The sixth is installation and payment friction. App availability, SMS verification, payment methods and rising costs (including the October 2026 tariff increases) can block access to VPN clients or top-ups even if the network path exists. A client installed before travel, with configurations saved offline, is far more useful than a download link that depends on the filtered network.

The seventh is legal risk. Starlink is illegal, and possession or use carries prison sentences. The current draft would require ISPs to authenticate users and foreign platforms to maintain a physical presence in Iran, while an earlier bill would have criminalised VPN use. Technical workarounds do not remove legal exposure.

Relevant protocols#

OpenVPN and WireGuard are poor choices against a protocol whitelist. Both have recognisable handshakes and packet formats, and neither is designed to look like ordinary HTTPS. Obfuscation can change the signature, but it does not change the endpoint address or the fact that a long-lived tunnel carries the traffic.

Shadowsocks and VMess add obfuscation and are widely used in Iran. They can pass some DPI, but a classifier that watches packet sizes, timing and entropy can still separate them from normal browsing. A working client today can fail after a rule update.

VLESS with REALITY addresses SNI filtering and naive probing. VLESS adds no inner TLS layer, and REALITY borrows the handshake of a real site, so a probe sees a genuine certificate. It does not hide the endpoint address, the volume of traffic or the fact that a shutdown has removed the path. The cover site also has to be reachable from the filtered network, which is not guaranteed.

Hysteria2 runs over QUIC and can perform well on lossy links, but Iran’s UDP restrictions make it a fragile default. A TCP-based TLS transport is slower but more likely to survive a network that throttles UDP. The practical answer is usually a TCP fallback, not a single QUIC-only configuration.

Maronix keeps improving its server configuration and setup against these findings, testing deployments on restricted networks and changing the details that stop working instead of treating one reachable setup as permanent.

Practical considerations#

• Install the client and save configurations before you travel. A shutdown can remove access to download pages, app stores, account recovery and payment flows.
• Keep more than one transport and more than one endpoint. A TCP/TLS option and a UDP option cover different failure modes.
• Test UDP separately. A tunnel that works over TCP may fail over QUIC or Hysteria2 when the network throttles UDP.
• Test the actual services you need, not just the tunnel handshake. A connection can open and still be too slow, platform-blocked or filtered to use.
• Check whether a name resolves to 10.10.34.34 or a block page. That identifies DNS interference before you change the tunnel.
• Test the SIM or access tier you will actually use. A white SIM and an ordinary mobile account do not share the same path; Internet Pro is gateway-based whitelisting, not a user VPN.
• Test mobile data and Wi-Fi separately. Behaviour can differ by operator and access tier.
• Test NIN vs global separately. If domestic sites work but global ones don’t, that’s a shutdown/whitelisting boundary, not a broken tunnel.
• Separate throttling from shutdown. A slow connection may mean shaping; no international connectivity means the border path is closed and no client protocol can restore it.
• Treat Starlink as a legal and physical-risk decision, not a normal fallback. Terminals are illegal, jammed and actively searched for.
• Expect shutdowns and friction. App-store access, SMS verification and payments can fail even between shutdowns. This page describes network behaviour, not legal advice.

Atlas articles#

• How Often Do Countries Shut Down the Internet? - shutdowns as a separate layer from filtering
• What Is Internet Censorship? - the five layers behind DNS, SNI and protocol blocking
• What Is Deep Packet Inspection? - how middleboxes classify encrypted traffic
• Why a VPN Can Work Today and Fail Tomorrow - address, protocol, probe and path failures
• What Makes a VPN Resistant to Censorship? - protocol, address, provider, placement, probing and operations
• What Is VLESS? - the proxy core used inside REALITY
• What Is REALITY? - borrowed handshakes and probe resistance
• What Is Hysteria2? - QUIC transport and its trade-offs

The useful question is which layer stops a connection, because that determines whether a tunnel can help. A VPN can move traffic around an address block or a protocol signature. It cannot create a path through a mobile network that has been reduced to an approved list of destinations.

Current situation#

The core of the system is TSPU, short for “technical means of countering threats.” These are hardware and software systems installed at telecommunications operators and controlled by Roskomnadzor, the state communications regulator, through the Main Radio Frequency Center. Operators carry the traffic. They do not decide what the filter does with it.

By October 2023, Roskomnadzor said TSPU covered every communications node in the country. The equipment can block addresses and domains, identify protocols, throttle traffic and enforce allowlists. It also gives the regulator a point inside each network where the same policy can be applied at scale.

The visible result is not uniform. Fixed-line users often encounter address and protocol blocks while domestic services continue to work. Mobile users can encounter something more severe: a whitelist shutdown in which the network carries only approved sites and services. Human Rights Watch dates the wider use of these shutdowns to spring 2025, and they have continued through 2026.

Scale is significant. By February 2026, the authorities had blocked at least 469 VPN services under the 2017 law that requires circumvention tools to respect the state blocklist. Human Rights Watch cites an estimate that about 40% of Russia’s population, or 57 million people, use a VPN. In August 2026, Human Rights Watch, citing Exploit, reported that 20 VPN providers had suffered service disruptions from blocking.

Those numbers describe pressure on circumvention, not the end of it. Some services remain reachable. Some protocols still work on some networks. The pattern is a moving target, and the sections below separate the layers that move.

Known techniques#

TSPU is the part most often described as a firewall, but the comparison hides the design. A national firewall usually sits at the border. TSPU sits at the operator, close to the subscriber. That placement lets the state apply different rules to different networks and lets it combine filtering with subscriber-level information held by the carriers.

The Russian system also uses the law as a filtering layer. The 2017 rules did not ban VPNs outright. They required VPN services not to provide access to blocked resources, and required operators to block services that failed to comply. Later measures added fines for VPN operators, banned VPN advertising, and made VPN use an aggravating factor in certain criminal cases. The effect is to raise the cost of running a service and to make some uses legally riskier than others.

Recent events#

February 2026. The count of VPN services blocked under the 2017 law reached at least 469. Around the same period, Human Rights Watch reported that Apple had removed 468 “utility” applications, a category that includes VPNs, from its App Store in 2025 in response to Russian requests.

15 April 2026. Major Russian sites and services began blocking visitors with active VPNs. The Moscow Times confirmed access denials on Ozon and Kinopoisk, with similar reports from banking and ride-sharing apps. The move coincided with a reported government deadline for more than 20 large platforms to curb VPN use.

June 2026. Russian authorities attacked Amnezia VPN with bulk IP blocking, phishing against staff and distributed denial-of-service traffic. One developer said full restoration took about six weeks. On 26 June, a law change prohibited Russian hosting providers from serving VPN services that bypass blocks.

4 August 2026. Human Rights Watch, citing Exploit, reported that 20 VPN providers had suffered disruptions. A representative told the organisation that the blocking targeted large IP ranges and entire subnets, which takes longer and costs more to replace than individual addresses.

21-25 September 2026. After the State Duma elections, ten VPN services reported tighter restrictions within a week. One large service said blocking peaked on 25 September. Another replaced eight servers in five days. Two others said Roskomnadzor had blocked all their foreign server locations and the IP addresses of all their servers. The VPN Guild described the wave as a continuation of pressure that began in early August, not a new campaign.

8 October 2026. Meduza reported that the draft federal budget for 2027-2029 would nearly double the annual TSPU subsidy to about 19.8 billion to 19.9 billion rubles. The three-year total is nearly 60 billion rubles for traffic filtering and internet blocking.

16 October 2026. Kommersant reported that a draft national AI plan through 2030 proposed using AI to identify VPN characteristics, with a claimed 95% blocking effectiveness. The Digital Development Ministry said the current draft contained no such measure. Industry sources said behavioural analysis could find VPN servers faster but would likely produce false positives during training.

27-29 October 2026. The Digital Development Ministry announced restrictions on mobile internet inside Moscow’s Third Ring Road during the Russia-Africa and Gas Exporting Countries Forum summits. The ministry said exempt websites, voice calls and Wi-Fi would remain available. The restriction is a temporary, location-specific version of the mobile allowlist model.

27 October 2026. Forbes reported that the Digital Development Ministry was considering routing all foreign traffic through TSPU equipment and capping each user’s foreign data. The proposal could cover home internet as well as mobile networks, and would likely be included in a telecom bill. The ministry said the measures were still under review. No final quota has been published.

Effects on users#

The first distinction is the access path. On a fixed connection, a working tunnel can still route around many address and protocol blocks. On a mobile connection under a whitelist shutdown, the network may carry only approved destinations, so the VPN endpoint is not reachable at all. Switching to Wi-Fi or a wired connection can change the result because the restriction is applied to the mobile path, not to the account.

The second is the type of block. A protocol signature can be defeated by changing how the traffic looks, but a bulk subnet block can remove every server in a provider’s range at once. Services respond by replacing addresses, which is why one provider can lose eight servers in five days and still operate. The cost is visible to users as reconnects, changed endpoints, slower speeds and intermittent failures.

The third is the platform layer. A VPN can be working at the network level and still fail against a Russian site that refuses connections from known VPN addresses. Ozon, Kinopoisk and other large services began doing this in April 2026. Some users respond with split tunneling or by disabling the tunnel for those services, which trades one kind of access for another.

Installation and payment are part of the same problem. App-store removals and payment restrictions make it harder to obtain a client after a block is announced. A client installed before travel, with configurations saved offline, is more useful than a download link that depends on the same network that is being filtered.

Relevant protocols#

WireGuard and OpenVPN are the clearest examples of a protocol problem. Both have recognisable wire formats. WireGuard’s fixed header and handshake make it easy to classify, and Russia blocked WireGuard traffic in 2023. OpenVPN has more configuration options, but its common profiles are also well known to filters. Obfuscated variants can change the signature, but they do not change the address, the volume of traffic or the fact that a single long-lived connection is carrying it.

VLESS inside REALITY addresses a different part of the problem. VLESS adds no encryption layer of its own, so there is no inner TLS session for a filter to detect. REALITY borrows the handshake of a real site, so a probe receives a genuine certificate instead of an answer from a VPN server. That removes two structural signals. It does not hide the server address, the amount of traffic or the behaviour of the target site.

Hysteria2 takes another route. It runs over QUIC and UDP, which can perform better on mobile links where packet loss is the main obstacle. It is not a universal answer. A network that throttles or blocks UDP can make it unusable, and a whitelist shutdown removes the path before the protocol matters.

The practical lesson is that protocol choice is one layer. Address diversity, hosting provider, probe response and operational testing decide whether a working configuration stays working. A strong protocol on a blocked subnet is still unreachable.

Maronix keeps improving its server configuration and setup against these findings, testing deployments on restricted networks and changing the details that stop working instead of treating one reachable setup as permanent.

Practical considerations#

• Install the client and save configurations before you need them. App-store access and account recovery can fail on the same network that blocks the service.
• Test mobile data and Wi-Fi separately. If mobile data is under a whitelist, a VPN will not restore it; a fixed connection may behave differently.
• Keep more than one transport and more than one endpoint. A single address is a single blocklist entry.
• Test the services you actually use, not just the tunnel handshake. A connection can open and still fail against a platform that rejects VPN addresses.
• Treat legal risk as separate from technical risk. Russian law restricts VPN advertising and treats VPN use as an aggravating factor in some criminal cases. This page describes network behaviour, not legal advice.
• Expect change. A configuration that works this week can fail after an enforcement wave, and the reason may be an address, a protocol signature or a platform rule rather than the tunnel itself.

Atlas articles#

• What Is Deep Packet Inspection? - the inspection layer TSPU relies on
• Why a VPN Can Work Today and Fail Tomorrow - the four ways a working tunnel stops working
• What Makes a VPN Resistant to Censorship? - protocol, address, provider, placement, probing and operations
• What Is VLESS? - the proxy core used inside REALITY
• What Is REALITY? - borrowed handshakes and probe resistance
• How Often Do Countries Shut Down the Internet? - shutdowns as a separate layer from filtering

Hysteria2 is a proxy protocol that runs over QUIC, the UDP-based transport defined in RFC 9000, with the unreliable datagram extension from RFC 9221. It forwards TCP and UDP between a client and a server, and its own specification describes the job in one line: a TCP and UDP proxy built for speed, security and censorship resistance.

The “2” matters. Hysteria 2.0.0 was a near-complete rewrite of the original Hysteria, with a new wire protocol, and a Hysteria 1 client cannot talk to a Hysteria 2 server. On the client side the binary can expose a SOCKS5 or HTTP proxy, redirect TCP, or run a TUN interface, which is how it ends up behaving like a VPN in everyday use. The protocol underneath is a proxy, not a layer-3 tunnel.

What problem it solves#

Two problems, and they pull in the same direction: packet loss and censorship.

Loss first. TCP treats packet loss as a sign of congestion and slows down, which is the wrong response on a last-mile link where loss comes from a noisy radio path rather than from a full queue. QUIC runs over UDP and lets the sender choose its own congestion control. Hysteria2 uses that room to offer Brutal, a controller that holds a declared rate instead of backing off when packets drop. The docs are direct about the trade: Brutal is “particularly effective at seizing bandwidth in congested, best-effort delivery networks, hence its name,” and it only works if the rate you declare is close to what the path can carry.

QUIC also removes one TCP failure mode. A lost packet stalls only the stream it belongs to, not every connection sharing the same TCP socket. That helps when one HTTP/2 or HTTP/3 session carries several requests.

Censorship is the second problem, and it is the reason for the HTTP/3 front door. Hysteria2 was designed so that a server without the password looks like an ordinary HTTP/3 web server, and so that an active prober gets a plausible web response rather than a proxy error. Everything else in the censorship story, from masquerade content to port hopping, is built around that first decision.

How it works, at the depth that matters#

• Transport: TCP connections become QUIC bidirectional streams. UDP packets become QUIC datagrams; packets larger than a datagram are split into fragments with the same packet ID, and the receiver discards the whole packet if any fragment is lost. That last detail explains why Hysteria2 does not speed up UDP traffic such as HTTP/3: it can carry the packets, but it cannot replace the congestion control of the application at either end. The project’s own HTTP/3 page says so plainly and suggests disabling HTTP/3 in the browser or blocking UDP 443 when the tunnel is in use.
• Handshake: the client sends a POST /auth request over HTTP/3 with a Hysteria-Auth header, a receive-rate hint, and random padding. A successful login gets status 233 HyOK; anything else means failure. A server that does not recognise the request is supposed to behave like a normal web server or forward it upstream. After the 233, the same QUIC connection switches to the Hysteria proxy protocol. The disguise covers the handshake and the probe, not the traffic that follows.
• Masquerade: because a stranger can reach the server, it has to have something to show. masquerade can serve a directory (file), reverse-proxy another site (proxy), or return a fixed string (string). If the section is missing, every HTTP request gets a 404. The docs also offer optional HTTP/HTTPS listeners on ports 80 and 443 so the host answers ordinary TCP requests too, while noting there is no evidence that firewalls are using the absence of those listeners to detect Hysteria servers. That note is worth keeping: the feature is for going further than the threat model requires.
• Congestion control: Brutal is used when a bandwidth value is present; otherwise the client falls back to BBR (the default) or Reno. The handshake carries the client’s receive rate, and the server can answer with its own or with auto. A server owner can set ignoreClientBandwidth to disregard client hints and keep the non-Brutal controller, which is the fairer choice on a shared box. Setting Brutal above what the link can carry produces the opposite of the intended result: a slow, unstable connection and wasted data.
• Obfuscation: two layers exist. Salamander XORs every QUIC packet with a BLAKE2b-256 hash of a password and a random salt, which removes the QUIC shape entirely. Gecko wraps Salamander and splits long-header handshake packets into 2 to 8 randomly sized, randomly padded fragments, so the handshake no longer has the packet-size signature of QUIC. Gecko is marked experimental. Both need the same password on both ends, and both make the server incompatible with standard QUIC: once enabled, it is no longer a valid HTTP/3 server. Obfuscation vs encryption separates the two properties.
• Client-side camouflage: recent releases add two smaller measures. The client fragments its TLS ClientHello, which can get past filters that look for a complete SNI in one packet, and it can parrot Chrome’s QUIC fingerprint, enabled by default since 2.11.0. ECH is supported as well, which hides the SNI from a middlebox that cannot decrypt it.
• Port hopping and fake TCP: a client can be given a list or range of ports and will switch between them on an interval, with optional random timing; the server can listen on a Linux port range and redirect the rest with nftables or iptables. This targets a specific behaviour: a block or throttle that follows one UDP port. It does nothing when the network drops UDP as a class, which the port-hopping page states directly. Mimic, a separate eBPF tool, rewrites UDP packets with a fake TCP header so the flow looks like TCP on the wire. It is Linux only, needs root on both ends, must be enabled identically on both sides, breaks existing clients when switched on, and cannot be combined with port hopping.

What it explicitly does not do#

• Survive a blanket UDP block. Port hopping is per-port by design. Mimic changes the appearance but still sends UDP underneath, and it carries the Linux and root requirements with it.
• Work behind a CDN. The HTTP/3 masquerade lasts until authentication. After that, the connection is a custom protocol no CDN speaks, and CDNs terminate QUIC with their own stack anyway, which would remove the Brutal advantage.
• Borrow someone else’s identity. A Hysteria2 server authenticates with its own certificate, obtained through ACME or supplied as a file. With a self-signed certificate the client either trusts the CA or runs insecure with pinSHA256. There is no equivalent of REALITY borrowing a popular site’s handshake.
• Hide the flow. The server address, the volume, the duration and the timing remain visible to anyone watching the path. Masquerade answers a prober; it does not make a long, busy UDP flow inconspicuous.
• Be a fair neighbour by default. Brutal holds a rate and compensates for loss. On a congested access link that can take capacity from other traffic, which is why the server has an option to ignore client bandwidth.
• Act as a layer-3 VPN on its own. The protocol is a proxy. TUN mode is a client feature that makes it usable as one.

How a censor sees it#

Start with what is visible before any password is sent. The flow is UDP, usually to port 443, carrying QUIC. QUIC encrypts its payload, but an on-path device can parse the Initial packet and, unless ECH is in use, read the SNI. That is not theoretical. Russia’s TSPU moved to SNI-dependent QUIC filtering between May 2022 and July 2023, according to a 2026 FOCI measurement study. China’s GFW began blocking QUIC connections to specific domains in April 2024 by decrypting Initial packets at scale, according to a USENIX Security 2025 study. Iran blocks UDP broadly, which the IRBlock measurement documents.

That evidence sets the boundary for every Hysteria2 feature. The HTTP/3 masquerade defeats a prober that connects without credentials and a classifier that expects something other than HTTP/3. It does not defeat an SNI blocklist, because the handshake still carries your domain, and it does not defeat a rule that drops UDP to a given address. Deep packet inspection is the general name for the reading that makes those rules possible. Obfuscation moves the traffic out of the QUIC category, at the cost of no longer looking like HTTP/3 to anyone. Gecko also changes the handshake’s packet sizes. ClientHello fragmentation targets filters that expect the SNI in a single packet, Chrome parroting targets fingerprinting, and ECH targets the SNI, with the usual caveat that a censor can block ECH or fall back to other signals. Port hopping answers per-port filtering; Mimic answers a network that allows TCP and restricts UDP, and trades away port hopping to do it.

The pattern is the one that applies to any single protocol: each measure answers a named filter, and a censor who changes the filter is not answered by the same measure. What Makes a VPN Resistant to Censorship? sets out the wider stack.

When it fits#

Good fit: the path is lossy or has high round-trip time, especially mobile or long-haul; the network allows UDP but treats TCP tunnels badly; you can state a realistic bandwidth figure; you control the server and can run Linux with root if Mimic is needed.

Poor fit: UDP is blocked or throttled as a class; you need a CDN in front; you cannot manage a domain and certificate; you want to borrow a popular site’s identity rather than present your own; you share a congested link and cannot afford to be unfair to other traffic.

Where Maronix fits#

Maronix will offer Hysteria2 as a second option alongside VLESS + REALITY. The reason is the trade this article describes: QUIC handles packet loss and high round-trip time well, and Hysteria2’s HTTP/3 masquerade and obfuscation answer a different set of filters than REALITY’s borrowed TLS identity. It is not a replacement. Where a network drops UDP as a class, VLESS + REALITY stays the better fit, and What Is Maronix? covers the rest of the stack.

Common misconceptions#

“Hysteria2 is invisible because it looks like HTTP/3.” The HTTP/3 shape covers the handshake and an unauthenticated probe. The SNI, the address, the volume and the timing are still there, and an SNI blocklist does not need to see inside the tunnel.

“Brutal makes any connection faster.” Brutal holds the rate you give it. Set above what the path can carry, it produces loss, retransmissions and a worse connection than BBR would have given you.

“Port hopping gets around a UDP block.” It gets around a block that follows one port. When UDP is dropped wholesale, every port in the range is dropped with it.

Related#

• What Is a VPN Protocol? — where a QUIC proxy sits among tunnels and proxies
• What Is WireGuard? — the UDP tunnel with no congestion-control ambitions
• What Is VLESS? — the proxy core that leaves encryption to its transport
• What Is REALITY? — the opposite bet: borrow a live site’s handshake
• Obfuscation vs Encryption — the distinction behind Salamander and Gecko
• What Makes a VPN Resistant to Censorship? — the six layers a single protocol cannot cover
• Why Maronix Uses VLESS + REALITY — the reasoning behind the current pairing

Encryption and obfuscation are the two separate answers. They are independent properties: a stack can carry one, both, or neither, and the interesting question is usually which one is missing rather than how much of each you have.

Short answer#

Encryption is a claim about what an observer can compute. With a correctly implemented cipher and a key that has not leaked, recovering the plaintext is infeasible for any adversary whose resources you can bound. The claim rests on mathematics, so it does not weaken when the observer gets better at watching.

Obfuscation is a claim about what an observer can classify. Given the bytes on the wire, the observer cannot tell which tool produced them, or cannot tell that a tunnel is present at all. The claim rests on a particular opponent’s present capabilities, so it weakens as soon as that opponent measures something you did not account for.

Neither one replaces the other. A tunnel that is perfectly encrypted and trivially recognisable is unreadable to everybody and blockable by everybody. A tunnel that is perfectly disguised and weakly encrypted is invisible right up to the moment somebody opens it.

What encryption is actually promising#

Encryption answers one question and answers it completely: once the bytes are in flight, what can an observer do with them. For a correctly implemented modern cipher, the honest answer is nothing useful. This holds whether the observer is a home router, a national filtering system, or the operator of the network carrying the packets.

Three properties make that claim unusually solid.

• It is adversary-independent. The guarantee does not depend on guessing what the opponent will try next. A stronger opponent gets a proportionally harder problem, rather than a different one.
• It is testable. You can verify an implementation against its specification, audit its key schedule, and formally analyse its protocol. The WireGuard handshake has been through exactly that treatment, with published proofs of its key indistinguishability and authentication properties.
• It degrades predictably. When encryption breaks, it breaks because somebody found a mathematical weakness or stole a key. Both events are visible after the fact, and neither is a routine Tuesday.

What encryption does not do is stop anyone from noticing that the encrypted thing is there. Every byte still has to travel, in some pattern, at some rate, between two addresses. Those are properties of the network rather than of the cipher, and they survive intact.

What obfuscation is actually promising#

Obfuscation answers a narrower question and answers it temporarily: given this stream, can an observer put it in a labelled box. The label might be “OpenVPN”, “a proxy”, or simply “something being hidden”. Any label the observer can attach is a label a filter can act on.

The weakness is structural rather than accidental. Obfuscation is a claim about another party’s capabilities, and that party is not obliged to publish its measurements. There is no proof to check, no specification to audit, and no way to know from the outside how much the opponent has already learned. A design that is indistinguishable today can become a signature tomorrow without any change on your side.

The Tor Project’s pluggable transport specification is built around exactly this problem. Its answer is architectural: obfuscation is decoupled from the core protocol and implemented as a transform that a separate process applies, so a new transport can be deployed without touching the protocol underneath. That separation exists precisely because the transforms have to be replaced repeatedly, while the protocol does not.

The cost side is real too. Camouflage has to look like something, and looking like something costs bandwidth, latency or both. Randomising packet lengths defeats a classifier that leans on size distribution. Forwarding unauthorised connections to a real website means your server now depends on that website’s behaviour and address range.

Three ways to hide a tunnel#

Obfuscation is not one technique. There are three strategies, and their track records differ sharply. Conflating them is the fastest route to misreading a protocol’s documentation.

Mimicry#

The tool imitates a named protocol. SkypeMorph pretended to be Skype; StegoTorus pretended to be HTTP. The design goal was unobservability, and the approach was to copy every externally visible property of the target.

This strategy has the worst record of the three. Houmansadr, Brubaker and Shmatikov analysed a set of these systems and reported that they completely fail to achieve unobservability, demonstrating dozens of passive and active techniques that distinguish the imitation from the real thing. The failure is not a matter of a missing patch. Imitating a protocol means reproducing every observable aspect of it, including packet sizes, timings and the full range of edge-case behaviour, and a classifier only has to find one discrepancy.

Look-like-nothing#

The tool abandons resemblance and instead removes structure. obfs4, the protocol Tor uses by default, describes itself as a look-like-nothing obfuscation protocol. It randomises packet lengths and timing so that the stream carries no repeating shape for a classifier to learn.

This sidesteps the failure mode of mimicry. There is no target protocol whose every detail you must reproduce, so there is no discrepancy for a prober to find. What it cannot do is make the traffic resemble ordinary browsing, which means it remains distinguishable from the traffic of someone who is not using a circumvention tool at all. It buys you an unlabelled box, and nothing more.

Borrow an identity#

The tool makes the server answer as something it is not. An unauthorised connection is forwarded to a real website, which completes a real handshake, so a probe receives a genuine certificate issued by a genuine authority for the site it asked for.

This is the strategy that survives probing, because the response is real rather than simulated. Cloak implements it by serving a fronted HTTPS site to anyone who is not authenticated. REALITY implements it by having Xray pass unauthorised traffic to a target site, with the project’s own documentation describing it as a modified form of TLS that uses the appearance and handshake characteristics of a target site as camouflage.

The project’s own word for it is camouflage. It describes REALITY’s contribution as an appearance problem, and the design spends its effort there rather than on adding cryptography.

Where OpenVPN and WireGuard end up#

Both protocols sit firmly on the encryption axis, and neither was designed with the appearance axis in view.

WireGuard is the clearest case. It is a layer-3 tunnel over UDP with a fixed set of primitives and no cipher agility at all. Its wire appearance is WireGuard on UDP, and the protocol has no mechanism to vary that. The project does not claim resistance to blocking, and there is no obfuscation built in. On an unrestricted network that is a strength: fewer moving parts, a smaller code surface, a design you can audit. On a network filtering tunnels it is a signature.

OpenVPN is more interesting, because it appears twice. Its tunnel runs inside TLS, so at a glance the traffic is TLS, which is the most ordinary thing on the internet. That superficial resemblance is not the same as indistinguishability, and the difference is where the evidence is sharpest.

A study published in Communications of the ACM fingerprinted OpenVPN from the position of an adversarial internet provider, using byte patterns, packet sizes and server behaviour as the three features. Working with a million-user ISP, the framework identified over 85% of OpenVPN flows with negligible false positives. The result that matters for this article concerns the obfuscated variants: the framework still identified 34 out of 41 commercial configurations sold as obfuscated, and the authors found most of those implementations resembled OpenVPN with a simple XOR patch applied, which is trivially fingerprintable.

Gene Tsudik’s technical perspective on that paper put the asymmetry plainly: designing VPN software is not rocket science, while designing an effective obfuscation layer is much more difficult.

Where VLESS + REALITY end up#

The pairing reverses the usual shape, and it is worth stating without hedging.

VLESS carries no encryption of its own. Its documentation describes a stateless protocol with no cryptography, whose entire job is to move an address, a port and a payload. Security is delegated entirely to whatever transport carries it. On its own, VLESS is an unencrypted forwarding format.

REALITY supplies the transport, and it does so by modifying TLS rather than by wrapping it. That distinction has a concrete consequence the Xray project warns about: pairing REALITY with a proxy protocol that has its own encryption produces a nested TLS-in-TLS structure, which is visible and has already been targeted. Because VLESS contributes no inner layer, the whole visible surface of the connection belongs to the transport.

So the confidentiality of this stack comes from TLS. The camouflage comes from TLS as well, modified so that the server borrows a real site’s handshake and the client emulates a browser fingerprint. Both of the properties people attribute to the combination are properties of the transport layer, and the proxy core supplies neither.

That is a coherent design rather than a weakness. It removes the nested structure that gives away wrapped tunnels, and it answers active probing by handing the prober a genuine certificate. What it does not do is add a second guarantee on top of TLS, and a configuration that skips the client fingerprint setting gives away on the first connection what the server side was built to conceal.

How the common stacks divide#

The useful question for any given stack is who supplies each of the two properties. Once that is answered, most of the confusion clears.

Two rows deserve a second reading. OpenVPN gains its camouflage from the same layer that gives it confidentiality, which is why improving one does not improve the other: the fingerprint lives in how the TLS is used, not in whether it is used. And Cloak sits in its own row because it demonstrates the separation directly. It is not a proxy; it is a pluggable transport that enhances traditional proxy tools including OpenVPN, which means obfuscation was added as an independent layer to a stack that already had complete encryption.

What neither one buys#

Stated plainly, because overclaiming here is worse than saying nothing.

• Volume and duration stay visible. One long-lived connection to one address is still one long-lived connection to one address, and that holds whether the tunnel is encrypted or disguised.
• The server address stays exposed. A certificate borrowed from a real site does not change the address the connection goes to. Anyone who already knows the address can resolve the borrowed site and compare the two.
• Behaviour remains informative. A filter modelling expected traffic for a destination can still notice an outlier. Doing that reliably against a varied population of targets is an open research question, and Atlas treats it as one rather than as a solved problem in either direction.
• Neither property transfers to the endpoints. The exit server sees the origin, and the destination sees the exit. Both are outside what any transport layer can address.

Choosing which gap you can live with#

The choice stops being “which is stronger” once the two axes are separated, and becomes a question about the network you are on.

• On a network that does not filter tunnels, the appearance axis is close to irrelevant, and encryption plus operational quality is the whole of the decision. WireGuard’s small surface and audited handshake are the right answer for most people most of the time.
• On a network that classifies and blocks tunnels, the appearance axis decides whether the encryption is ever used at all. Correct cryptography on a connection that gets reset in the first second protects nothing.
• If you need to survive probing, only the borrowed-identity strategy answers it. Mimicry fails on measurement, and look-like-nothing leaves you distinguishable from everyone who is not circumventing.
• If you can only change one layer, change the one that is failing. A WireGuard tunnel blocked by recognition does not need better cryptography. An obfuscated tunnel whose inner protocol leaks through needs its wrapping redesigned, and adding a second encryption layer inside TLS reintroduces the nested structure the design exists to remove.

Maronix runs VLESS with REALITY, which puts it in the bottom row of the table above, and the rest of what that means is covered separately in why Maronix uses that pairing.

Common misconceptions#

“Encryption and obfuscation are the same defence.” They fail under different conditions and are supplied by different layers. A stack that has one has gained nothing on the other axis.

“If my traffic is encrypted, nobody can tell what I am doing.” Nobody can tell what it says. That it is a tunnel, and which tool produced it, are questions about shape and timing, and the OpenVPN fingerprinting study answered both for a widely deployed protocol.

“Obfuscation makes a protocol insecure.” It makes it more complex, and complexity has a cost. The failure documented for commercial obfuscated VPNs was detection rather than a cryptographic weakness, which are different problems with different fixes.

“Wrapping a protocol in TLS hides it.” Wrapping something inside an already-encrypted layer leaves a nested structure that is itself a signature. This is the specific warning the Xray project gives about pairing REALITY with protocols that carry their own encryption.

“The newest protocol is the most censorship-resistant one.” WireGuard is newer than OpenVPN, simpler, and better audited, and it has no camouflage whatsoever. Recency and resistance to classification are unrelated properties.

Related#

• What Is Deep Packet Inspection? — the classification problem obfuscation exists to evade
• What Is a VPN Protocol? — why framing is one of the four questions a protocol has to answer
• What Is VLESS? — the proxy core that contributes no encryption
• What Is REALITY? — the transport that supplies both properties in this pairing
• What Is WireGuard? — the opposite bet: all the cryptography, no camouflage
• What Is Hysteria2? — a protocol where the two properties are separately switchable

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:

1. Protocol — what the bytes look like
2. Address — which IPs, how many, how fast they change
3. Provider — whose network those IPs sit in, and what that provider’s incentives are
4. Placement — whether blocking you means blocking something else the censor needs
5. Probing — what your server does when an unauthorised client connects
6. 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#

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

What internet censorship is already states the mechanism in a single line: a tool can work for months and then stop working with no change to the tool, because something moved down the stack. This article is the evidence behind that line, and a taxonomy of the four distinct ways it happens.

Short answer#

Four mechanisms account for almost every documented failure of a working VPN in the last five years. They are worth separating because they call for different responses.

• The censor learns a signature. Detection precedes blocking, and the identification is the durable half of the operation.
• The censor escalates between levers. Addresses, protocols, hosting subnets and app distribution are separate levers, and the record shows them pulled in sequence.
• The censor applies a block unevenly, or takes it back. Mobile and fixed networks behave differently, regions differ from one another, and a national filter has finite capacity.
• Somebody other than the censor moves. Cloud providers, app stores and payment processors have removed circumvention capability through ordinary business decisions, with no government order involved at all.

Only the first is what most people picture when they think of a VPN being blocked. The other three appear at least as often in the record, and the fourth is not censorship.

Detection comes first, and it lasts#

Nothing is blocked before it is identified, and identification is the part that does not get rolled back. A block can be lifted; a signature, once published or once learned by a classifier, sits in the system permanently.

Roskomsvoboda’s study of Russian circumvention cites a 2022 CensoredPlanet experiment that identified 85% of traffic going through OpenVPN. The study behind that number is worth reading for its framing rather than its figure: the classifier was trained on flows from an ordinary internet provider position, using byte patterns, packet sizes and server behaviour, which are all properties a client cannot stop having.

The same asymmetry shows up in the obfuscated case. Commercial VPNs sold as OpenVPN-with-a-wrapper were fingerprinted at scale, and the authors found that most implementations resembled plain OpenVPN with a simple transformation applied. That detail matters for the escalation story below, because it means the censor does not need to break encryption or mount an active attack. It needs one stable observable, and stability is exactly what a widely deployed client provides.

Escalation between levers#

Russia’s last five years are the best-documented case of a censor working through a list of levers rather than finding one decisive move.

The chronology, drawn from Roskomsvoboda’s report and contemporaneous trade press:

• June 2021. VyprVPN and Opera VPN blocked by name.
• September 2021. Hola, ExpressVPN, KeepSolid VPN Unlimited, NordVPN, Speedify and IPVanish blocked by name. In the same month, users on Rostelecom and Beeline mobile networks began reporting WireGuard connection failures, which Roskomsvoboda reads as an early TSPU attempt that also caught Avito, Twitch and other unrelated services.
• 23 January 2023. In the eastern regions, IKEv2 and OpenVPN protocols were blocked, while the IP addresses of the VPN servers themselves remained available.
• 30 May 2023. Partial blocking of OpenVPN, IKEv2 and IPSec.
• August 2023. OpenVPN and WireGuard clients stopped working, reported primarily by users of Beeline, Megafon, MTS, Tele2, Tinkoff and Yota. Traffic on landline and business connections largely kept flowing. At least 6 of 15 popular services lost access.
• December 2025. TSPU settings updated; SOCKS5, VLESS and L2TP placed under active disruption.
• February 2026. Roskomnadzor reported 469 circumvention services blocked, up from 439 in January and 258 in October 2025.

Three things in that list deserve more attention than the dates themselves.

The January 2023 entry is the cleanest natural experiment in the public record. The protocol was blocked and the server address was still reachable. Those are two different layers of the censorship stack, and an operator who can act on one is not thereby able to act on the other. It also means the failure a user experiences is not diagnostic on its own: a connection refused for protocol reasons and a connection refused for address reasons look identical from the client.

The August 2023 entry shows the same escalation pattern from the other side. The block was real, and it was partial. It applied mainly to mobile networks, which is where the volume of ordinary residential traffic sits, while business and landline accounts carried on. That distinction is not a technical curiosity. It is the difference between a policy that targets the general population and one that spares foreign companies still operating in the country.

The 2025 and 2026 entries show that the escalation did not stop at protocols. Human Rights Watch reported in September 2026 that the recent waves targeted VPN services’ infrastructure directly: large blocks of IP addresses, including entire subnets allocated by their hosting providers. One affected service told the organisation that restoring access after bulk subnet 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 being a tenant on somebody else’s network goes up sharply.

Blocking is applied unevenly and can be reversed#

A national filtering system is a physical installation with finite throughput, and it does not behave like a logical switch.

Roskomsvoboda’s study notes that Russian TSPU blocks are enforced differently per region, which ValdikSS attributed to local filtering capability rather than to any announced policy. The August 2023 OpenVPN and WireGuard failures followed the same shape: mobile operators in the lead, fixed lines largely untouched, and access restored on 8 August 2023 after roughly a week.

The capacity limit is documented too. Mediazona reported in April 2026 that a source in the telecoms market described current TSPU infrastructure as not always coping with traffic volume, with the practical consequence that blocked resources occasionally became accessible. The same reporting described a Ministry of Digital Development plan to expand TSPU capacity two-and-a-half times by 2030.

Iran provides the measurement complement to the Russian case reports. The IRBlock study, presented at USENIX Security 2025, measured the whole of Iran’s IP address space over 2.5 months and tested more than 500 million apex domains. It recorded 6.8 million addresses subject to DNS poisoning and HTTP blockpage injection, 5.4 million subject to UDP disruption, and over 6 million censored fully qualified domain names. It also found that blanket blocking of entire top-level domains caused large collateral damage to innocuous websites, which is the same failure mode Roskomsvoboda observed in Russia in September 2021 when Avito and Twitch went down alongside the intended targets.

The pattern generalises: a filter that is aggressive enough to catch a target is usually aggressive enough to catch neighbours, and the neighbours are politically expensive.

When the censor steps back#

The clearest documented reversal is the August 2023 restoration. Roskomsvoboda records that access to the blocked protocols was restored on 8 August 2023, and that on the evening of that day the availability of all services was restored. The same report notes that VPN connections from abroad into Russia continued to work throughout, which reads as a deliberate carve-out rather than a gap.

A subtler form of stepping back is the VLESS episode. In late 2025, reports circulated that Roskomnadzor had blocked VLESS, one of the more advanced circumvention protocols. Mediazona’s April 2026 account is more careful with that claim, and its caution is the instructive part: the reality was more nuanced, and most VPN providers responded by issuing new configurations to their users. Disruption is not removal. A protocol can be degraded enough that every existing client configuration stops working, while the protocol itself continues to function once the parameters change.

That distinction is why “is VLESS blocked in Russia” is the wrong question. The right question is what the block looks like, how long it takes to work around, and what the workaround costs.

Somebody other than the censor moves#

This is the section most coverage of VPN blocking omits, and it is the one with the strangest failure record.

Domain fronting is the case study. The technique, formalised in a 2015 paper by Fifield and colleagues, made a request to a blocked service indistinguishable from a request to a popular CDN-hosted domain, because the censor could see the outer name but not the inner one. The Signal Foundation described the censor’s dilemma plainly: to block one domain-fronted site you have to block the rest of the internet as well.

It worked for years. Then the providers closed it, one after another, on their own schedule:

• 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.

None of those decisions was a censorship order. They were policy changes by companies that did not want their infrastructure used as a front, and they removed a capability that circumvention tools had depended on. Tor’s response was to move its domain-fronting traffic to Azure, and a Tor spokesperson told CyberScoop at the time that the project had moved all of its domain-fronting to run there.

The Russian case supplies the other half of the story, and it is the half that connects to the provider layer. When Telegram was blocked in April 2018, Roskomnadzor blacklisted millions of IP addresses belonging to Google and Amazon CDN infrastructure. Mediazona’s account of that episode notes that Hetzner space was caught in the same sweep, and that the effort was eventually abandoned. Psiphon’s Michael Hull, asked about the technique at the time, told CyberScoop that domain fronting on its own is not very effective, that it has to be combined with obfuscation, HTTP header modification and transport fragmentation to defeat a sophisticated censor, and that the importance of a diversified circumvention toolbox cannot be overstated. He also observed that the technique breaks the CDN design, which is a concise explanation of why the CDNs stopped tolerating it.

Two more vectors from the same period complete the picture. Apple removed 468 utility applications, a category that includes VPN clients, from its Russian App Store in 2025, and by early 2026 the company had removed several named VPN apps on Roskomnadzor’s demand. In March 2026, Russia’s four largest mobile operators were ordered to stop allowing Apple account top-ups from mobile phone billing, which removed a common way of paying for those apps. Neither of these is network filtering. Both are effective.

What the pattern implies#

If reachability is a property of the environment, then asking whether a VPN is blocked is the wrong unit of analysis. Four questions are better:

• Which layer is being acted on right now? Address, protocol, provider subnet, app distribution and payment are all different layers with different remedies.
• Is the block total, partial or reversible? The record contains all three, often for the same protocol in the same month.
• Who else could move? A capability that depends on a cloud provider’s terms of service has a different failure schedule from one that depends on a censor’s budget.
• What is the recovery path, and what does it cost? Bulk subnet blocking is explicitly described as slower and more expensive to recover from than address-level blocking, and that cost lands on the operator rather than the user.

Obfuscation and encryption answer the detection question, and they answer it well. What they do not answer is which addresses the operator has left, which subnets those addresses sit in, whether the app store still distributes the client, or whether the payment rail still works. Those are infrastructure questions, and they are covered separately in who controls the infrastructure.

Those questions are the job description of whoever runs the network, and they are answered by practice rather than by a feature. Maronix treats reachability as ongoing work: the team researches detection methods, including DPI, and blocking techniques as they appear, provisions and replaces nodes as subnets get caught in bulk blocks, and tracks how networks in restricted places behave from one week to the next. A tool configured once and left alone eventually meets a censor that has moved. An operator still working the four layers above usually moves first.

Common misconceptions#

“If my VPN works, it is working.” It is working at this moment, on this network, at this layer. The August 2023 Russian block was real for mobile users and absent for landline users on the same days.

“A blocked protocol is a dead protocol.” VLESS was reported as blocked in late 2025 and most providers responded by shipping new configurations. Degradation and removal are different events.

“Blocking is permanent.” Access to OpenVPN and WireGuard in Russia was restored on 8 August 2023 after roughly a week of disruption. Restoration is documented, not hypothetical.

“Encryption is what fails.” No cipher in this record was broken. Every failure above was a failure of reachability, classification or distribution, which are properties of the network and the supply chain rather than of the cryptography.

“It is always the censor.” Google, Amazon, Microsoft, Apple and Cloudflare have all removed circumvention capability or distribution through ordinary business decisions. The failure schedule of a technique can be set by a terms-of-service update.

Related#

• What Is Internet Censorship? — the five-layer model this article’s chronology is read against
• What Is Deep Packet Inspection? — the layer that produces the signatures detection depends on
• Obfuscation vs Encryption — what each one can and cannot answer about the detection problem
• What Is WireGuard? — a protocol whose wire appearance is itself the signature
• Who Controls the Infrastructure? — the layer where provider decisions become reachability decisions
• What Makes a VPN Resistant to Censorship? — the six-layer stack these failures are measured against
• What Is Maronix? — the service whose answer to these four questions is an ongoing practice

That distinction matters more than it sounds. Neither of the two clients recommended below is a Maronix product, neither ships servers of its own, and neither sells a VPN subscription. Both are open interfaces for a connection profile that you already hold. You can change one for the other on the same day, on the same subscription, and lose nothing except the settings you had made.

This guide covers two clients across five operating systems: where to download each one, how to install it, and how to add the Maronix subscription so the locations appear in your server list. It stops there. Choosing a location, connecting and finding out whether the tunnel is actually working are separate steps, and How to Check That Your VPN Is Working covers the last of them.

What you’ll need#

• A Maronix account. Request one through the channel. Account and billing both run through Telegram, so this is the first thing to have working.
• Your subscription. The panel gives you two forms of the same thing: a subscription URL to paste, and a QR code to scan. Either one is enough on its own.
• A supported device. Android, iOS, Windows, macOS or Linux. Both clients also reach TV platforms if you need one.
• Ten minutes. Longer the first time, faster every time after.

Choosing between Happ and INCY#

Both clients are built on the Xray core, and both support VLESS with REALITY, which is the pairing Maronix runs. On the protocol side they are interchangeable for this purpose. The difference is maturity, and it is not evenly spread across platforms.

On maturity, take the developers at their word. The INCY project publishes this warning on its own download page, and it is quoted here rather than paraphrased:

The desktop client is pre-alpha. It is usable day to day, but expect rough edges and breaking changes between releases. Please report anything you hit at feedback.incy.cc — that is exactly what this stage is for.

Happ publishes no equivalent warning, ships arm64 builds alongside x64 for every desktop platform, and maintains documentation split into a user section for the general public and a technical section for developers. For a first install on a laptop or desktop, that combination is the safer route. On mobile the two are much closer, and either one is a reasonable pick.

Installing Happ#

Download from happ.su, which lists every build in one place. The documentation lives at docs.happ.info.

On Android#

1. Open the Google Play Store and search for Happ, or install the APK directly from the official site if your device has no Play Store.
2. A separate beta APK is published for anyone who wants unreleased builds.
3. Android TV uses the same Google Play package.

On iOS#

1. Install from the App Store using the Global listing.
2. TestFlight builds are published for both the Global and Rus editions if you want to run a preview.

On Windows#

1. Download the setup installer for your architecture: x64 for most machines, arm64 for ARM-based ones.
2. Run the installer and start Happ when it finishes.

On macOS#

1. Install from the App Store, or download the universal dmg and drag Happ into Applications.

On Linux#

1. Take the package for your distribution: deb for Debian and Ubuntu, rpm for Fedora and Red Hat families, and an Arch pkg.
2. Both x64 and arm64 variants of each are published.

Adding your Maronix subscription to Happ#

Happ documents three ways to add a configuration. The subscription route is the one to use for Maronix, because it keeps updating without you re-entering anything.

Method 1: subscription link (recommended)#

1. Copy the subscription URL from the Maronix panel.
2. Open Happ and press the + button in the upper right corner of the main screen.
3. Choose the subscription option and paste the link, or scan the QR code instead of pasting.
4. Save. The locations appear under the server list on the main screen.

Method 2: QR code#

1. Take the QR code from the panel on a second device, or display it on the device you are setting up.
2. Press +, choose the QR option and allow camera access when prompted.
3. Save once the servers have been read.

Method 3: single link or manual entry#

1. If you were given a single vless:// link rather than a subscription, copy it and add it through the URL option. Happ reads vless://, vmess://, trojan://, ss://, socks://, hysteria2:// and hy2://.
2. If you were given raw parameters, press +, choose manual input, pick VLESS from the protocol list, fill in the fields and press Done.
3. Manual entry is the fallback, not the default. Anything entered this way has to be updated by hand when a server changes.

One detail worth knowing: Happ distinguishes between a standard subscription, which is an ordinary web URL, and an encrypted one whose link begins with happ://crypto. Both work, and in the encrypted form the server settings and the subscription URL are hidden.

Installing INCY#

INCY is distributed through the app stores and through GitHub, where the desktop installers live. The official site is incy.cc.

On Android#

1. Install from the Google Play Store, or sideload the signed APK from GitHub.
2. Android TV uses the same Play Store package.
3. Releases are versioned independently per platform, so an app update notice on one device does not imply an update elsewhere.

On iOS#

1. Install from the App Store. The same listing covers iOS, macOS and Apple TV.

On Windows#

1. Download the setup installer, or the portable zip if you would rather not install anything.
2. Both x64 and arm64 builds are published. Remember this is the pre-alpha desktop client.

On macOS#

1. Download the dmg for your processor: Apple Silicon or Intel.
2. Drag INCY into Applications and open it.

On Linux#

1. Take deb, rpm or Arch pkg for x64 or ARM64, whichever matches your distribution.
2. A portable zip is published as well for systems where you cannot install packages.

Adding your Maronix subscription to INCY#

INCY imports a subscription from a URL, a QR code or a share link, and refreshes it automatically so server changes arrive on their own.

From the subscription URL#

1. Copy the subscription URL from the Maronix panel.
2. Open INCY and add a new subscription.
3. Paste the link. The servers populate the list, and the subscription card shows the name given to it.
4. Leave automatic refresh enabled.

From the QR code#

1. Display the QR code from the panel.
2. Add a new subscription and scan instead of pasting.
3. Save once the servers have been read.

From a single server link#

1. If you hold a vless:// link instead of a subscription, import it the same way. INCY also reads vmess://, trojan://, ss://, socks://, wireguard:// and hysteria2://.
2. A single link gives you one server with no automatic updates, so it suits a one-off test rather than daily use.

INCY’s subscription body may be base64-encoded links, plain links one per line, or a full Xray configuration in JSON. A provider chooses the format; the client accepts all of them. That is a detail you only need if something fails to import, and it is the first thing to ask about if the panel’s link is rejected.

Which client for which device#

There is no single answer, because the two clients are not equally finished everywhere.

• On a laptop or desktop, start with Happ. No published pre-alpha warning, arm64 builds for every platform, and documentation written for end users rather than for integrators.
• On Android or iOS, either one. Both are mature on mobile, both read the same subscription, and switching costs nothing.
• If you want INCY on desktop anyway, take the portable build first so you can judge it without touching your system setup, and keep the GitHub releases page open.
• If you rely on a TV, both ship Apple TV and Android TV builds.

Install both if you are unsure. One subscription, two clients, and the only thing you lose is the settings you configured in the one you leave behind.

Troubleshooting#

Security considerations#

Both clients disclaim the servers in the same words: the servers are yours. Happ states that it includes no servers and provides no VPN service, and that it does not collect VPN data. What it does collect is crash reports and diagnostics through Sentry, plus a device identifier and the device model in the HTTP headers used to fetch subscription data, which the settings let you switch off. INCY publishes the same disclaimer, and adds that mobile builds include Firebase Crashlytics for crash reports while the desktop client sends no telemetry.

Four habits worth forming:

• Download from the developers, not from a search result. happ.su, which now also runs at happ.info, and incy.cc are the official sites; the GitHub organisations and app store listings are linked from them.
• Check the address before you type anything. A lookalike domain is the cheapest attack there is, and this is exactly the traffic that draws them.
• Treat the subscription URL as a credential. Anyone holding it can add your servers to their own client. Do not post it, and regenerate it if it leaks.
• Remember what the client cannot do. A client that is installed correctly still tells your network that you are using a tunnel, and it does not unlink the accounts you sign into afterwards. Privacy versus anonymity draws that line in full.

Once the servers are in your list, the useful next question is whether the tunnel does what you expect it to do. How to Check That Your VPN Is Working walks through the four checks that matter.

Related#

• What Is Maronix? — what the service is before you install anything for it
• Why Maronix Uses VLESS + REALITY — the protocol pair both of these clients speak
• How to Check That Your VPN Is Working — the four checks to run once you are connected
• What Is VLESS? — the protocol you select during manual entry

The service is in launch mode. The servers exist and are being tested against countries with restricted networks, the public site carries a start date rather than an operating history, and the fastest way to judge any of it on your own connection is the trial that ships with it.

This article describes what Maronix is built from and what that choice buys. It also separates that from the parts that a new service cannot have claimed yet.

Short answer#

Maronix is a censorship-resistant VPN. VLESS is the proxy core that moves your traffic, and REALITY is the transport that carries it. Together they produce a tunnel with no encryption layer of its own to give away and no certificate of its own to present, which is the whole reason that pairing exists.

Alongside the technology, three things shape how the service is actually used. Servers are tested where filtering is hardest rather than on an open route. A trial gives you enough days and enough traffic to test the session you normally have, not just a handshake. And access runs through Telegram, which you need to have working before anything else can start.

What it is built from#

Two components, doing two different jobs.

• VLESS is the proxy core. It moves an address, a port and a payload, and it holds no session state on the server. Because it adds no cryptography of its own, there is no inner TLS layer sitting inside the outer one for a filter to read. What Is VLESS? covers the framing.
• REALITY is the transport. Instead of presenting a certificate for a domain the operator had to acquire and defend, it borrows the handshake of a real, popular site. A prober gets a genuine certificate from a genuine authority; only an authorised client is forwarded into the tunnel. What Is REALITY? walks through the handshake.
• Independent infrastructure is the third element, and it is not a protocol. It answers a separate question: who physically holds the machine your traffic terminates on, and what can they be asked to hand over. Who Controls the Infrastructure? works through why that question survives every good protocol choice.

The two protocol articles above are worth reading before the next one in this series, Why Maronix Uses VLESS + REALITY, which takes the pairing apart layer by layer.

A second option is planned. Hysteria2, a QUIC-based proxy, will join the pairing above as an alternative rather than a replacement. It aims at a different condition: networks where UDP survives and packet loss is the main obstacle. What Is Hysteria2? explains what the protocol does and where it stops.

How access works#

Maronix is Telegram-first. The panel where you request an account and the process for billing both run through the channel, which puts the service on an unusual footing compared with the self-service dashboard most VPNs present.

The split is simple to state: the website carries the general information, and the Telegram channel carries the instructions and the access. The channel is where the how-to material lives; the site is where the project describes itself.

There is a practical consequence to that arrangement, and it is better found out now than later. You need Telegram working on your network before you can become a customer. On a network that filters Telegram, that is the first thing to solve. It is a narrow, checkable problem, and it is considerably easier than reaching a payment form behind the same filter.

The trial#

A trial ships with the service, sized generously in both days and traffic. The point of the sizing is that it has to outlast a real session rather than a curious first look.

An evening with a VPN tells you that a handshake completed. A trial that spans ordinary use tells you the things that fail first on a filtered network:

• whether social media feeds load and keep loading
• whether video plays without stalling every few seconds
• whether a stream survives long enough to be worth watching
• whether the connection still behaves like a normal modern internet session at the end of it

Those four are the honest test. Restricted networks tend to break them in that order, and a trial measured in minutes cannot reach the fourth one at all. Use the whole thing before deciding anything.

Servers tested where it is hard#

The project’s approach is to test the servers against countries with restricted networks rather than against an open route between two friendly data centres. That is the correct test, because the failures only appear when something in the path is actively participating: a blocked address, a connection reset mid-session, a handshake that gets answered by a filter instead of by the server you asked for.

Which countries are covered at launch, and how many servers sit in each, is not published yet. Treat the available locations as something you check on the day you start rather than something you plan around.

The idea behind the name#

The name comes from the Maroons, communities of people who escaped slavery and established autonomous settlements beyond colonial control, and from Hakim Bey’s Temporary Autonomous Zone: spaces that arrange their own conditions of freedom for as long as they can hold them.

Maronix carries that idea into the network rather than reproducing the history. Atlas, the knowledge base you are reading, is the other half of the pair: one project moves you, the other explains what it is made of.

The full account, including the crest and what each part of it stands for, is on the About page.

What Maronix does not claim#

Worth stating plainly, because most of these are the things a marketing page would leave out:

• A long track record. The service is in launch mode. Its public face carries a start date, not years of operation to point at.
• A published audit. There is no third-party audit result to link to yet. Verification available today is the trial, which tests behaviour on your connection rather than code review.
• A hidden server footprint. Independent infrastructure is a claim about who holds the hardware, and it can be checked the same way who-controls-the-infrastructure describes checking anyone else’s.
• Anonymity. A tunnel changes what your network between you and the destination can see. It does not unlink you from the accounts you sign into afterwards. Privacy versus anonymity draws that distinction in full.

Common misconceptions#

“Maronix is another VPN with a different logo.” The protocol pair is not a branding decision. VLESS inside REALITY is chosen because of two specific detection problems, and the article above explains what each component is for.

“Servers tested in restricted countries means the service is proven.” Testing shows the tunnel survived a particular path on a particular day. It is evidence about that path. It says nothing about jurisdiction, about operator structure, or about what happens when the path changes.

“A trial tells you whether a VPN is private.” A trial tells you whether a connection works. Privacy is a property of who runs the machine and what they keep, which is a separate line of enquiry and the reason level 5 of the Atlas Path exists.

Related#

• Why Maronix Uses VLESS + REALITY — the technical case for the pairing, taken apart layer by layer
• What Is a VPN? — what a tunnel changes before anyone gives it a name
• What Is VLESS? — the proxy core carrying the traffic
• What Is Hysteria2? — the planned second option, and the conditions it targets
• Who Controls the Infrastructure? — the question that outlives a good protocol choice

Maronix runs VLESS inside REALITY because that pairing addresses both questions, in different layers and for different reasons. This article takes the two apart, says plainly where each one stops, and keeps the two ideas separate. They are related, they are frequently described as one thing, and they are not interchangeable.

Short answer#

VLESS contributes the proxy core and deliberately adds no encryption of its own. Nothing nested sits inside the outer TLS session for a filter to read out as a second layer, because there is no second layer.

REALITY contributes the transport and deliberately adds no identity of its own. A server that gets probed answers with a genuine handshake borrowed from a real, popular site, and only an authorised client is forwarded into the tunnel.

One is what carries the traffic, the other is what the traffic appears to be. Neither does the other’s job.

The problem this pairing answers#

Internet censorship at the level this is aimed at is a classification problem rather than a content one: something in the path reads a stream of bytes, decides which of several categories it belongs to, and then acts on that decision.

Deep packet inspection is the general name for doing that deliberately. The techniques behind it are ordinary and well understood, from address and DNS blocks up through SNI filtering and TLS interference.

Encryption on its own answers none of it. A perfectly encrypted tunnel announces itself by behaving like a tunnel, and on networks where tunnels are the category being filtered, correct encryption is the thing that gets classified.

Two distinct signals give a classifier something to work with. The first is structural: nested layers, a distinctive handshake, a fingerprint that does not match any browser anyone ships. The second is behavioural: one long connection to one address carrying an unusual volume of traffic. This pairing addresses the structural signal directly. The behavioural one it leaves alone, which is covered further down.

What VLESS contributes#

VLESS is a stateless proxy protocol. Its frame is a version byte, a UUID, a command, a port, an address, and the payload. That is close to the whole design.

Three properties follow:

• No inner encryption. The protocol carries no cryptography of its own, so nothing has to be wrapped inside TLS and then hidden. The Xray project’s guidance is explicit that pairing REALITY with proxy protocols other than XTLS leaves clear TLS-in-TLS characteristics, and that those characteristics have already been targeted.
• No session state. The server validates a UUID and forwards. There is no session table to build, no per-request randomness to generate, which is what the protocol removed when it dropped the earlier response-authentication mechanism in favour of a leading version byte.
• A framing that looks like nothing. VLESS does not disguise itself. It relies on the transport to supply whatever appearance is visible, which is the division of labour the pairing depends on.

The consequence for detection is straightforward. With no inner layer to strip away, the entire visible surface of the connection belongs to the transport. Whatever the transport looks like, that is what the connection looks like.

What REALITY contributes#

REALITY answers the second question: what happens when something connects to the server directly and asks it to prove what it is.

A conventional TLS endpoint has to hold a certificate for a domain it controls. That domain is published, resolvable, and either hosted on the same address or discoverably associated with it. The operator hunting for the server starts from there. Behind that sits a fingerprint problem: extension ordering, cipher preference and session ticket behaviour differ between implementations, and they can be measured on the first connection before any authentication happens.

REALITY’s answer is to have no identity and borrow one instead:

• The client builds a ClientHello carrying a value the server can decrypt with its private key: a short ID, and a timestamp inside the session ID sealed with a key derived from the exchange.
• The server checks the short ID against its list and the timestamp against its allowed clock difference, then issues a temporary certificate signed by a temporary authentication key. Forward secrecy holds because the session keys come from the handshake.
• Anything that fails that check is forwarded to the real site, which completes the handshake before the response is passed back. The prober receives a genuine certificate from a genuine certificate authority for the site it asked for.
• The client must also look ordinary. The fingerprint setting emulates a browser’s client fingerprint, because without it the client side carries a signature of its own and the server-side work buys very little.

Server names have to be genuine too, since the certificate a non-authorised client sees has to match the target.

Why neither replaces the other#

This distinction is the one most often collapsed, and it is worth taking slowly.

VLESS without REALITY#

A tunnel with no security of its own and no camouflage. Over plain TCP it is an unencrypted forwarding format. Inside ordinary TLS it produces exactly the nested structure the project warns about, because the proxy protocol’s own framing sits inside the transport’s encryption.

REALITY without a proxy protocol#

Secures and disguises but does not forward. It is a transport. Something still has to take an address and a port and move the payload, and that is the job VLESS holds. REALITY can also only run on TLS-like transports, currently RAW, XHTTP and gRPC, which is another reason it is never the whole stack.

The pairing#

Neither half is a substitute for the other. Each one supplies the piece the other structurally cannot, which is why the choice appears as a pair rather than as a preference.

What this does not buy you#

Stated without hedging, because a protocol choice that gets oversold here is worse than one that gets described honestly:

• The address still identifies a server. The certificate belongs to the target; the address does not. Anyone who already knows the address can compare the two.
• Volume and duration remain visible. One long-lived connection to one address is still one long-lived connection to one address.
• Behavioural profiling remains open. A filter modelling expected traffic profiles for a destination can still notice an outlier. Doing that reliably across a varied population of targets is an open research question, and Atlas treats it as one.
• The target site becomes a dependency. Its behaviour, its address range and its popularity become operational concerns. The documentation also warns that a target sharing an address, as with a site behind a large CDN, effectively turns your server into a port forwarder for that CDN.
• The client is now a required part of the camouflage. A client that does not emulate a browser fingerprint gives away on the first connection what the server side was built to conceal.

What Maronix does with it#

For the service itself, the pairing is the reason the rest of the operating model exists. Servers are tested against countries with restricted networks rather than on an open route, because the failure modes only appear when something in the path is participating. A trial is sized in days and traffic so that a user can test social media, video and streaming on their own connection instead of reading a claim about them.

Both of those exist because no amount of protocol selection proves anything about your particular path. The tunnel has to survive your network, on your day, with your traffic. That is what the trial is for, and the channel is where the access instructions live.

Common misconceptions#

“VLESS + REALITY is a single protocol.” It is a proxy protocol and a transport. They are configured separately, versioned separately, and fail separately. Treating them as one name is the fastest route to misreading a configuration file.

“VLESS + REALITY is undetectable.” It removes two specific structural signals. Volume, duration, the server address and the behaviour of the target site all remain, and the client’s own fingerprint has to be handled correctly for the server-side work to mean anything.

“More layers would make it stronger.” Adding a second encryption layer inside TLS reintroduces the nested structure this design exists to remove. Strength here comes from having fewer distinguishable layers, not more of them.

Related#

• What Is VLESS? — the proxy core, defined on its own terms
• What Is REALITY? — the transport, including what it explicitly does not do
• What Is Deep Packet Inspection? — the classification problem behind the design
• What Is Internet Censorship? — the wider context this sits inside
• What Is Hysteria2? — the planned second option, and the trade it makes

Short answer#

Independence is a question about who can compel an operator and who owns it, and it is answerable. Look for a named parent company, a stated ownership structure, and a published answer to at least one legal request. A brand name settles none of that.

The brand is not the company#

Two services can share every visible property and differ completely in what you are trusting.

One sells to the widest possible audience, runs affiliate partnerships and review campaigns, and answers to shareholders. Another has two named owners, publishes the directive those owners operate under, and has never taken outside investment. Both will offer a no-logs policy, an audit, and a kill switch. Only one of them has to answer to anyone but its founders.

This is why operator structure belongs ahead of feature lists in any comparison. The features are the easy part to copy.

Three structures that actually exist#

Independent operators in this market tend to cluster into three shapes. Each is real, and each has a documented example.

Founder-controlled and uninvested. Mullvad states that Mullvad VPN AB and its parent Amagicom AB are 100% owned by founders Fredrik Strömberg and Daniel Berntsson, both still active in the company, and it publishes an owner’s directive setting out how they are bound. There is no investor class with a return expectation attached.

Foundation-controlled. Proton is a Swiss for-profit, Proton AG, whose primary shareholder is the Proton Foundation, a Swiss non-profit that by law has no shareholders of its own. Employees hold the majority of the remaining shares, with the balance split between another non-profit foundation and users. No change of control can happen without the foundation’s consent, which is what lets it block a hostile takeover. The foundation was created in 2024, and Proton pledges 1% of net revenue to it.

A listed holding company with a portfolio. Kape Technologies, formerly Crossrider, floated on the London Stock Exchange in 2014 and is controlled by Teddy Sagi. It has since acquired CyberGhost, ZenMate, Intego, Private Internet Access and ExpressVPN, the last for $936 million in 2021. Each of those brands markets itself as an independent service.

What each structure can and cannot do#

Ownership shape determines which pressures can reach you, and each has a limit.

Founder control removes the shareholder, which is the most common source of pressure toward monetising data. It does not remove the possibility of a sale, a succession, or a change of mind by the owners themselves.

A foundation with a veto removes the takeover. It does not make the company well run, and it does not remove the need to make money: Proton’s own founder has said the for-profit entity stays in place precisely so the mission can be funded.

A listed parent removes the founder’s discretion over direction and can reshuffle brands, accounting, and infrastructure policy. It does not make the service untrustworthy on its own. Plenty of well-run companies are owned by shareholders.

None of the three touches the second question, which is the subject of the next article in this level: who owns the hardware, and who can reach the disk.

The consolidation problem#

The reason brand names mislead is that the market has consolidated hard, and the acquisitions are public record.

Kape’s own history page lists the sequence: CyberGhost in 2017, ZenMate and Intego in 2018, Private Internet Access in 2019, ExpressVPN in 2021. It also bought Webselenese, a VPN review site, in 2021. One parent owning five VPN brands and an independent-sounding review publication is the clearest illustration available that neither a VPN brand nor a review site carries structural information.

The company’s earlier name is worth knowing too. Crossrider built browser extension technology whose monetisation options, as CNET reported, were used by major ad injectors, and Google and UC Berkeley named the company in a 2015 study. CyberGhost’s own CEO put the contrast plainly in a blog post since removed from the site: “while CyberGhost focused on privacy and security from day one, Crossrider started out as a company that distributed browser extensions and developed ad tech products. Quite the opposite of what we did.”

None of that says anything about how the services currently handle data. It says the founding story is not a technical property, which is exactly the point.

Where “independent” stops meaning anything#

Small and founder-run describes ownership, not operations. A two-person company and a listed holding company both depend on rented hardware in buildings they do not own, staffed by people they did not hire.

That is why the ownership question is worth asking and is not sufficient on its own. Independent of whom, and running on what, are two different questions with two different answers.

Common misconceptions#

“A no-logs policy means independent.” A policy describes logging. It says nothing about who owns the company, and it can be published by any of these structures.

“A non-profit is stronger than a for-profit.” Foundation control removes one specific risk, namely a hostile sale. Proton still operates a commercial company because that is what funds the work.

“Small companies are private by nature.” Employee counts describe staffing. A founder-run service can be careless with the records it does hold.

“The brand name is a guarantee.” Five brands under one parent share accounting, legal exposure, and infrastructure decisions. The logo does not show you that, and the comparison table certainly will not.

Related#

• What Should You Look for in a VPN?: the decision procedure this article feeds
• What Is a VPN?: why the operator’s position in the path matters at all
• Privacy vs Anonymity: the difference ownership is trying to buy you

Short answer#

Often, and more than most people outside the affected regions realise. Access Now and the #KeepItOn coalition documented at least 313 shutdowns in 52 countries during 2025, the highest annual total since they began tracking in 2016. People in 100 countries have now experienced one.

What a shutdown actually removes#

Internet censorship works in five layers of filtering, each of which can be lifted selectively. A shutdown is the opposite: it removes connectivity itself, usually by instructing networks to drop traffic, and it is indiscriminate by design.

The variants matter because they are not all total. A full national shutdown cuts everything. A partial one targets specific applications or specific regions. Blocking an individual communications platform is the narrowest version, and it is now the most common form by count.

None of these require deep packet inspection. That is the point. The most sophisticated filtering, deep packet inspection, is a precision tool, while a shutdown needs nothing more than a routing change.

Why they are used#

The purposes recorded in the data are not censorship of content in the usual sense. They are control of events.

Shutdowns cluster around elections, protests, armed conflict and communal violence, and they are frequently timed to specific hours rather than applied indefinitely. The goal is to prevent coordination during a moment of mass mobilisation, or to limit the reach of reporting about violence.

A secondary use is to hide what is happening on the ground. Where a shutdown coincides with an incident the state would rather not see reported, the outage is doing information work.

What the record shows#

Access Now’s Shutdowns Tracker Optimization Project is the most complete running record of deliberate shutdowns since 2016, and its annual report is the source for everything below.

The trend line is upward. The coalition recorded 289 shutdowns in 2023, 304 in 2024, and at least 313 in 2025. Seven countries appeared on the list for the first time in 2025.

Concentration is extreme. India recorded 65 shutdowns in 2025, its lowest count since 2017, and still leads every democracy by a wide margin. Since 2016 it accounts for 920 of 2,102 documented shutdowns worldwide. Myanmar led the 2025 total with 95.

What changed in 2025#

Three changes are worth a reader’s attention, and none of them is about volume.

Persistence. Some 75 shutdowns across 33 countries began in 2025 and continued into 2026. Temporary disruption during an event is one thing; a multi-month cutoff of a platform or region is a different instrument aimed at a different outcome.

Satellites came next. Authorities turned to Low Earth Orbit satellite internet systems, cutting them 14 times across seven countries, after four incidents the previous year. That is a sharp rise, and it extends shutdown policy to connectivity that does not pass through domestic fixed-line infrastructure at all.

Platform targeting grew too. Blocking of individual communications platforms reached a record 94 cases across 40 countries, up from 77 across 37 in 2024 and 58 across 27 in 2023.

Read together, these describe a shift from blunt national blackouts toward selective, targeted, and more durable interference.

What this means for a user#

A shutdown does not behave like censorship that a tunnel can route around. If the routing information is being withdrawn by every domestic network, a VPN cannot reconstruct a path that no network will carry.

What remains useful is narrower: an exit outside the affected country, if one is still reachable at all; an already-configured client, since a later attempt to install one may be impossible; and a plan agreed in advance, because the decision about what to do usually has to be made before the lights go out.

Limitations of the data#

The tracker is a curated dataset assembled from partner reporting, not a complete census, and it should be read as a floor rather than a ceiling. Undercounting is systematic rather than random: reporting a shutdown requires someone to observe it and someone to publish it, and both are harder where the consequences of being visible are severe.

Totals also move. The 2025 report revised the 2024 figure from 296 to 304 and the 2023 figure to 289, and states plainly that its numbers reflect the latest available data and include updates to previously published totals. An older figure that disagrees with a newer one is usually not an error; it is a superseded count.

Related#

• What Is Internet Censorship?: the filtering layers a shutdown replaces
• What Is Deep Packet Inspection?: the tooling on the other end of the spectrum
• What Does Your ISP See?: what remains visible when a shutdown is partial

Short answer#

Check four things separately: the address websites see, the resolver answering your DNS queries, whether IPv6 is inside the tunnel, and whether WebRTC can read your real address. Two of the four need a terminal.

Check 1: is the tunnel carrying your traffic#

The simplest test and the one everything else assumes. Load a page that reports the address it was reached from, with the VPN connected. If the address shown belongs to your network rather than your provider, the tunnel is not carrying browser traffic.

A more precise version catches split tunnelling and apps that report connected while the system route never changed: compare the country the page reports against the location you selected in the client. Both should agree.

Check 2: where your DNS queries are going#

This is the check most tools get wrong, and it is worth understanding why.

Name resolution is the first thing your device does for every hostname. If those lookups are answered by your network’s resolver instead of one inside the tunnel, the names you visit are exposed even though the traffic afterwards is not.

A browser cannot observe this. The page you are visiting sees only the result, not who returned it, which is why honest leak testers state that verifying DNS “needs an authoritative nameserver we control”. Anything a browser reports about your resolver is inference.

From a terminal, with the VPN connected:

nslookup -type=txt whoami.cloudflare 1.1.1.1
dig +short myip.opendns.com @resolver1.opendns.com

The first returns the resolver address Cloudflare saw querying. If that address belongs to your network while the VPN is on, DNS is leaking. Most clients have a setting along the lines of using the VPN’s own resolver or blocking outside DNS, and that setting is the actual fix.

Check 3: IPv6#

Browsers prefer IPv6 when a device has it. Many VPN clients tunnel IPv4 only, so a working IPv6 address bypasses the tunnel entirely and lands you at websites with your real one.

A passing check here is weak evidence, because a device that has IPv6 but happened to connect over IPv4 reads as a pass. Test it deliberately: confirm the address your client shows you is an IPv6 address, then confirm what sites see.

The fix is to disable IPv6 on the adapter, or to use a provider that tunnels it.

Check 4: WebRTC#

WebRTC lets browsers open peer-to-peer connections directly, and it discovers your public address to do it. A page can trigger that and read the result, which is how the original leak worked: Mullvad warned about it in 2015, describing a browser that exposes the real public IP of anyone connected through a VPN.

Firefox is the only mainstream browser that can fully disable it, via media.peerconnection.enabled set to false in about:config. Chrome on desktop offers no such control at all.

Brave is the partial answer, and it is closer than most pages admit. Brave exposes a WebRTC IP handling policy in chrome://settings/privacy, and its own documentation describes four settings rather than an on/off switch. “Default Public Interface Only” and “Disable Non-Proxied UDP” both mean local addresses are not exposed, and “Disable Non-Proxied UDP” is the default when Fingerprinting Protection is on. What Brave does not offer is a way to turn WebRTC off; it reduces what WebRTC can reveal, following the framework in RFC 8828, which explicitly recommends against blunt disabling because it breaks applications.

For the specific risk this check exists to catch, a Brave user with Fingerprinting Protection on is in reasonable shape. The distinction is that reduced exposure and no WebRTC are different things, and only Firefox offers the second.

What still leaks when every check passes#

Green results are worth something. They are not a guarantee.

Mullvad’s 2024 application audit, carried out by X41, recorded a finding for exactly this case. On Linux and Android, the kernel replies to ARP requests for any local address, so an attacker on the same local network can learn the address of your tunnel interface, and because that address rotates monthly, potentially identify the device over time. Mullvad rated it medium severity, noting it discloses little about the user, and cited its padding and noise packets as partial mitigation.

A local network observer can tell you are running a VPN even with all four checks green.

Reading the results#

A leak is not automatically a failure of your provider. It is more often a configuration problem, and the check tells you which one.

Real address showing means the route did not change. Local resolver showing means the client’s DNS setting is off or unsupported. IPv6 showing means the tunnel does not cover it. WebRTC showing means the browser needs a policy change.

Common misconceptions#

“A green check proves the VPN works.” It proves the check you ran passed. Different tools check different subsets, and browser-only DNS tests check something a browser cannot actually observe.

“Leak tests are objective.” Most are third-party pages reading what your browser exposes to a stranger. That is useful signal and not a security boundary.

“Disabling WebRTC is the only fix.” It addresses one path. IPv6 and DNS leaks reach the same places without WebRTC being involved at all.

“A passing test means nobody can tell.” The operator and the datacentre can still reach things your test cannot see.

Related#

• What Is a VPN?: what the tunnel changes, which is what these checks confirm
• What Should You Look for in a VPN?: choosing something worth testing
• Who Controls the Infrastructure?: the checks above do not cover the operator

Short answer#

Two things carry the weight. Who operates the server you connect to, and what they can be compelled to hand over. Everything else you will read in a comparison is either identical across providers or irrelevant to the risk you actually care about.

The second question is the one people skip. There is no universally best provider, because the answer depends on who you are defending against.

Begin with the adversary#

A VPN changes what your network sees. It does not change what the service you log into already knows, and it does not change who follows you afterwards.

That makes the useful first question narrow. Are you trying to stop a curious network, or are you trying to stay unlinked from an adversary that can compel the operator? The two need different things, and most of the marketing copy on offer answers neither one directly.

Privacy versus anonymity draws this line in full. The short version is that a single tunnel buys you the first situation and has very little to offer against the second, which is also why the rest of this level keeps returning to who is running the machine.

The properties that actually vary#

Only a handful of things differ meaningfully between providers. They are worth sorting into two groups.

Who operates the server. Some operators publish who owns them. Mullvad states that Mullvad VPN AB and its parent Amagicom AB are entirely owned by two named founders, and publishes an owner’s directive alongside that structure. Other operators tell you only that a brand exists.

What they were ever asked for. This is checkable, and few pages surface it. As displayed in 2026, IVPN’s transparency report lists 34 government requests between 2016 and 2026, of which three were judged valid, with data provided in none of them. That is a stronger signal than a policy promise, because it describes what happened rather than what is intended.

What they keep regardless. Every service needs enough state to run a network. Connection metadata, which servers are busy, how many people are online at once. The useful question is never whether any of this exists. It is whether any of it can be joined back to you.

How the service is funded. If revenue comes from selling data, the privacy policy is not a technical document. Most subscription services avoid this, but it is worth thirty seconds of checking.

The properties that are the same everywhere#

Worth naming explicitly, because these eat most of the attention in comparisons.

Encryption standard, protocol availability, kill switch behaviour, and the presence of a no-logs claim all have near-universal answers among services large enough to review. AES-256 with a modern handshake is the norm. WireGuard, OpenVPN and their variants are all present. A kill switch is a feature every serious provider ships.

Where a provider does differ here, it is usually because they left the mainstream, which brings its own costs. The protocol trade-offs are covered separately, and none of them are free.

What no provider can fix#

This is the part that gets left out of every comparison table.

A VPN does not touch what the sites you visit know about you. It does not stop a browser fingerprint. It does not hide which accounts you hold, and it will not help if the machine itself is compromised. If any of those is your actual concern, the tunnel is the wrong tool and no amount of provider diligence will change that.

None of this makes a VPN a poor choice. It makes a VPN a specific choice, covering a specific set of problems.

How to check a claim rather than accept it#

Three habits separate a real check from reading a marketing page.

Look for the weakest specific claim rather than the strongest general one. Mullvad’s policy lists what it does not keep, down to DNS queries and connection timestamps, which is checkable in a way that “we take your privacy seriously” is not.

Look for a published answer to a legal request. A provider that has never been asked has told you nothing either way.

Treat third-party verification as dated and scoped. An audit describes one system on one week, and the scope is usually printed on the cover.

Common misconceptions#

“A no-logs policy makes a provider trustworthy.” A policy is a statement of intent. It becomes evidence when something external tests it, such as a seizure finding nothing, or a transparency report showing requests refused.

“Independent means safe.” Small and founder-run describes ownership, not operations. A two-person company and a listed holding company both depend on rented hardware in buildings they do not own.

“The fastest service is the best service.” Speed is a property of the path to you, not of the operator’s ethics. It rarely correlates with anything you care about here.

“Audited means verified.” An audit covers a snapshot. Read the scope before you read the verdict.

Which one should you pick#

Pick against a specific adversary and the choice gets easy. If you want a company network to stop logging your browsing, a mainstream provider is fine and the decision barely matters. If you want a record to exist nowhere that can be requested, the operator’s structure and the location of the hardware both narrow the field sharply, and the comparison pages will not tell you how.

The two articles that follow this one work through that field: who is actually behind the brands, and who controls the machines.

Related#

• What Is a VPN?: what a tunnel changes and what it leaves alone
• Privacy vs Anonymity: the distinction this decision turns on
• What Does Your ISP See?: the visibility a VPN actually removes
• What Is a VPN Protocol?: why protocol differences matter less than they seem to

Short answer#

Control follows the hardware. A provider can promise anything in a privacy policy and still lose the argument if the machine sits in a jurisdiction its owner cannot refuse, on infrastructure whose operator can be compelled separately. The practical consequence is simple: where the server is decides how much the policy is worth.

The chain from your device to the disk#

Four parties stand between your traffic and a disk you cannot inspect.

You pay a service. That service rents machines, either directly from a hosting provider or from a datacentre operator who rents space and power. The datacentre connects to transit and peering networks. At each step somebody else can act: the service can be compelled, the hosting provider can be compelled, the datacentre operator can be raided.

The first-order effect, that whoever runs the server can see both ends of your connection, is covered in What Is a VPN?. This article is about the second-order effect, which is that the same party may not be the one holding the hardware when someone comes with a warrant.

The same test, opposite outcomes#

Physical seizure is the closest thing the industry has to a controlled experiment. Investigators take the machine and look at what is actually on it. Four well-documented cases make the point better than any policy comparison.

ExpressVPN, Istanbul, January 2017. Turkish investigators were tracing the deletion of messages from the accounts of the police officer who assassinated the Russian ambassador to Turkey, and the trail led through an ExpressVPN exit address. The server was seized from the datacentre. It held no customer connection logs. ExpressVPN’s statement says the seizure occurred before they were contacted, and that the investigators’ inspection confirmed the company had nothing to hand over.

IPVanish, 2016. Homeland Security Investigations traced an IP to Highwinds Network Group, which owned IPVanish at the time. The first summons was answered with a refusal, on the grounds that no usage logs existed. A second, more detailed request produced a username, a full name, an email address, an IP address and the connection logs for one user. The user was traced to Muncie, Indiana, and arrested.

PureVPN, 2017. The provider handed connection logs to UK authorities in the Ryan Lin case. PureVPN’s privacy policy now states explicitly that it logs no browsing activity, connection timestamps, original IPs or DNS queries, and separately describes a deployment option that permits logging when instructed by authorities.

Perfect Privacy, Rotterdam, August 2016. Dutch authorities seized a server. Perfect Privacy confirmed no customer data was obtained.

Four seizures. Two produced nothing. Two produced an identity. The variable was never the protocol or the price tier.

Why “no activity logs” is not the same as no logs#

The IPVanish case is the one worth understanding, because the provider was not lying in the way the story usually assumes.

Connection logs and activity logs are different things. An activity log records what you did. A connection log records that an account with a given internal IP was active at a given time, which is enough to align one person with one session. The IAPP analysis of these cases puts it plainly: the information that broke both investigations was connection metadata, not browsing history.

This is the same distinction privacy versus anonymity draws, applied to an uncomfortable corner of the industry. A provider can state truthfully that it records nothing about what you did and still hand over everything needed to work out who you are.

The honest version of a no-logs claim is therefore specific. Mullvad’s policy lists what it does not keep, down to connection timestamps and DNS requests. PureVPN’s policy, as above, is careful about the gap. Those two pages are doing something different from a marketing sentence.

Who owns the building#

Placing a server in a country you cannot influence is a liability no policy can offset, and one provider has documented learning this the hard way.

After the 2017 seizure, ExpressVPN stopped operating physical servers in Turkey and switched the Turkish location to a virtual one, serving a Turkish IP address from hardware in the Netherlands instead. Users see no difference. What changed is which country’s authorities can walk into the datacentre.

The broader pattern is that most large providers rent from third-party hosting and cloud providers, and some publish little about which. Where a provider discloses its datacentre operators, that disclosure is the most useful single document it publishes, because it tells you which governments can reach the hardware.

Self-hosting as the third option#

The third option is to remove the provider from the chain, and it is a real one.

Running the server yourself means no operator sits between your traffic and the disk. It also means you own the patching, the uptime, the abuse complaints, and every configuration mistake. WireGuard is the usual choice here precisely because a small protocol surface is what makes that ownership realistic.

Self-hosting also removes your only advantage as a customer. When something breaks at 2am, you are the support desk, and no amount of structural independence substitutes for someone else holding the pager.

How to check for yourself#

Three checks are cheap and rarely done.

Ask who owns the company behind the brand, then follow commercial versus independent VPNs for what that structure can and cannot promise.

Ask whether the provider publishes a transparency report counting legal requests received, requests judged valid, and requests answered with data. IVPN’s report lists 34 requests received between 2016 and 2026, three judged valid, and none answered with data.

Ask what happens if the hardware is seized. If the answer is only a policy, the seizure cases above are your reference.

Common misconceptions#

“RAM-only servers make seizure pointless.” A diskless machine has nothing to seize, which helps. It does nothing about a compelled request to the operator, and it does nothing about connection metadata that never touches the disk.

“The provider’s jurisdiction is enough.” Jurisdiction binds the company. The hardware may sit somewhere else, and the datacentre operator answers to its own government.

“A transparent network is not a transparent operator.” Showing users the exit IP list describes your product, not your legal exposure.

“Self-hosting is strictly safer.” It removes one party and adds several duties, including ones you cannot delegate.

Related#

• Commercial VPN vs Independent VPN: who owns the company above this chain
• What Is a VPN?: the first-order effect of the tunnel itself
• What Should You Look for in a VPN?: the decision procedure this article supports
• Privacy vs Anonymity: why connection metadata can identify you

Short answer#

• Privacy you can have most of the way with a VPN or encrypted DNS. The contents of your traffic stop being readable to the network.
• Anonymity you can only get from arrangements specifically designed for it, and even then only within limits that the designers state plainly rather than deny.

A VPN gives you privacy. It does not give you anonymity, and a provider who says otherwise is either confused or selling something.

What privacy actually means#

Privacy in the network sense is control over who learns facts about you from watching your connection. It is a spectrum, not a switch:

• Your ISP knows your IP and the domains you resolve. Not private.
• Through a tunnel, your ISP knows you are talking to one server and nothing more. Mostly private.
• The tunnel operator knows your IP, and if they log, knows where you went. Private from one party, exposed to another.

Notice what is happening in that last line. Privacy was moved rather than achieved, and that is the most important thing to understand about the subject, and it is the reason “which VPN should I use” is the wrong first question. The right first question is “who am I actually trying to hide things from”.

What anonymity actually means#

Anonymity is the stronger property: no observer, no matter where they sit, can link your activity to you as an individual.

Getting there requires solving at least three problems at once.

Linkability across the network: you must ensure that nobody can tie this connection to that connection. A single tunnel does not do this. The operator of the tunnel endpoint sees both your address and the destination. Tor distributes the path across several relays so that each one only ever learns its own two neighbours, which is why its own documentation describes the design in exactly those terms.

Linkability at the destination: even if the network cannot tell who you are, a site can, through a login, a cookie, a fingerprint, a payment, an account you already have. Tor’s overview is blunt about this: Tor cannot solve all anonymity problems, it focuses only on protecting the transport of data, and you need additional tools if you do not want the sites you visit to see identifying information about your computer.

Linkability in behaviour: the shape of your activity can identify you even when its contents cannot. A pattern of when and how often you connect, and to what kind of destination, is a fingerprint of its own.

This is why anonymity is a project, not a purchase.

What each one buys you#

Why the two get confused#

Three reasons, in order of how much damage they cause.

Marketing accounts for a lot of it. “Private and anonymous” is a common phrase because it sells. A product that changed your IP address is often described as making you anonymous, which it does not do, because the operator of that product knows exactly who you are.

Moralisation accounts for some of the rest. Privacy is sometimes treated as the responsible choice and anonymity as something suspicious. This is backwards as engineering: the situations where you need to be unidentifiable are overwhelmingly the situations where you have least power. Treating it as inherently illicit removes the option exactly when it is needed.

Assuming one implies the other: people reasonably hope that if the traffic is hidden, the person is too. There is no mechanism connecting the two.

Common misconceptions#

“A VPN makes me anonymous.” It does not. The tunnel endpoint sees the connection arriving from you and the connection leaving for your destination. Unless the operator discards that data and can be shown to, your activity is available to exactly one party, by design.

“Anonymous browsing just means being logged out.” Being logged out of an account removes one identifying link. It leaves every other one: your address, your browser, the destinations you visit, the times you visit them.

“Anonymity is strictly better.” It is not free and not always available. It costs throughput. It makes you suspicious to systems that flag anonymous traffic. Many sites block it outright, which turns an anonymity tool into a practical loss of access. For most people trying to keep a connection open, privacy is the goal and anonymity is a different, more expensive project.

“If I cannot be identified, nothing I do is attributable.” Not identifying who you are and not being accountable are different properties. Treating them as the same thing is how people talk themselves into doing things they would not do if identified, and how governments acquire consent that could not otherwise be given.

Which one should you want#

Answer this before choosing any tool, because the answer changes what you should buy.

• You want your network not to read or log your traffic. That is privacy. A tunnel and encrypted DNS are proportionate.
• You want the destination not to know it is you. That is a bigger problem. It starts with the accounts you use, not the protocol you choose.
• You need to act without any party being able to attribute it to you. That is anonymity, it requires tools designed for it, and it comes with a cost and a set of documented limits you should read rather than assume.

And underneath all three: who specifically are you hiding this from? The answer is not “everyone” in the abstract. It is one party, or a small number, and the right tool depends entirely on which.

Related#

• What Does Your ISP See? — the concrete list of what is visible before you do anything
• What Is a VPN? — what a tunnel gives you, and the party it introduces
• VPN vs Proxy vs Tor — the three tools compared against the two properties

A proxy moves one connection through someone else. A VPN moves your whole device’s traffic through someone else as well. Tor spreads that traffic across several someones in sequence, so that none of them knows both ends.

Summary#

The difference that matters most: a proxy hides a destination, a VPN hides your entire route, and Tor makes the route unlinkable to any single party.

How they differ#

A proxy forwards requests#

A proxy is the simplest of the three. Your application asks the proxy to fetch something, the proxy does it, and you receive the result. It has been specified in this form since SOCKS, the protocol defined in RFC 1928, which describes a small handshake for asking a server to connect elsewhere on your behalf.

Two consequences follow from “one connection”:

• It only covers applications configured to use it. Everything else goes direct, and your network sees it.
• The proxy operator knows your address and what you asked it for, because both facts are in front of it.

A proxy is the right tool for one application reaching one destination, with no throughput cost.

A VPN moves the whole device#

A VPN is a network interface. Your operating system sends packets into it, they travel encrypted to a server, and the server sends them onward. Applications do not need to know. That is the difference from a proxy, and it is why a VPN hides your DNS lookups and background traffic as a side effect of carrying your traffic rather than relaying it.

The cost is a party. A VPN operator necessarily sees your address and, if it logs, everything you did through it. This is covered in What Is a VPN?; the honest summary is that the risk is moved, not removed.

Tor makes the route unlinkable#

Tor adds something neither of the others has: it splits your traffic across multiple relays so that no single one knows both ends. As the Tor Project’s own documentation puts it, a circuit is extended one hop at a time and each relay knows only which relay gave it data and which relay it is giving data to. No individual relay ever knows the complete path.

That design has a second half. Because the destination is a website you log in to, network-level anonymity is not enough on its own, because the site would still identify you. Tor Browser addresses this separately by making every user’s browser look alike: its manual describes limiting the variety of screen sizes, fonts and languages so that large numbers of users fall into a small number of buckets, which makes identifying any one of them much harder.

So anonymity under Tor is two projects stacked: an unlinkable network path, and a browser that resists identifying you on its own. A VPN does the first and never attempts the second.

Performance#

Roughly, in order: proxy is fastest, VPN next, Tor slowest. Tor costs more than throughput: circuits are built one hop at a time before your first request completes, and many sites deliberately slow down or refuse traffic that looks like Tor.

Tor pays for that design instead: circuits are built one hop at a time before your first request completes, and many sites deliberately slow down or refuse traffic that looks like Tor. The cost is accepted by a network built to carry it.

Detection#

Each is recognisable, and each is recognisable in a different way.

• A proxy is the hardest to see from the network, because a well-configured proxy looks like ordinary traffic to a single destination. It is also the easiest to forget about, and the traffic you forgot to proxy is the traffic that gets seen.
• A VPN is a recognisable object on the wire. A tunnel has a shape, and shapes can be measured. Encrypted VPN traffic is statistically distinguishable, which the CACM paper on OpenVPN fingerprinting measured; deep packet inspection covers how that works in practice.
• Tor is openly identifiable, deliberately. Its relays are published and its client announces itself. The Tor Project’s own summary of this is that all anyone monitoring can see is that you are using Tor. That is a design decision: it makes Tor easy to block, and in exchange it needs no attempt to blend in.

When to use which#

Use a proxy when one application needs to reach one place, and you care about that destination rather than about your whole device. Lower overhead, one point of trust, and a much narrower claim than a tunnel makes.

Use a VPN when you want your network to stop seeing where you go, for everything you do, at a throughput cost you can live with. This is the right default for public Wi-Fi, for daily browsing, and for most people reading this.

Use Tor when you need no single party to be able to link your activity to you, and you can accept the speed and the fact that some sites will refuse you. Journalists, whistleblowers, people in repressive environments, and anyone whose safety depends on the separation holding.

Use two of them when the threat demands it. Tor over a VPN, or a VPN over Tor, exists because the two properties are different: one hides your route from the network, the other hides your identity from the relay.

What none of them do#

None of the three changes who you are to a website you are logged into, and none protects you from malware, from a convincing phishing page, or from behaviour that identifies you. A search for one very specific rare thing defeats all three equally.

And all three are visible to a network operator as something. What differs is whether the operator can tell which destination, which is a very different question from whether they know you are tunnelling.

Common misconceptions#

“A proxy is a smaller VPN.” It is a different tool for a different job. It covers one connection, requires per-application configuration, and gives its operator both ends of that connection.

“Tor is just a VPN with more steps.” The added steps are the point. A VPN operator can see both ends; that is a structural property of a single-hop tunnel, not a configuration mistake.

“If a proxy is enough, why bother with Tor?” Because “the proxy cannot read it” and “the proxy cannot prove it was me” are different guarantees. Pick based on which one you need.

“HTTPS already handles this.” HTTPS protects the contents of one connection. It does not hide your destination from your network, and it does nothing for the cases in this article where the network is the observer.

Related#

• What Is a VPN? — the mechanism behind the middle column
• Privacy vs Anonymity — the property the right-hand column actually delivers
• What Does Your ISP See? — the observer all three are trying to hide from

Short answer#

Without a tunnel, the operator of your network can see:

• Your IP address, and that the traffic belongs to you.
• Every domain name you resolve. A DNS lookup is a question asked in the open.
• Every server you connect to, by IP address and port.
• When, how much, and in which direction.
• The name of the site you are connecting to, in most cases, sent in cleartext as part of the TLS handshake.

What it normally cannot see:

• The contents of an HTTPS page. TLS 1.3 does this properly, and there is no weakness in it worth worrying about here.

The gap between those two lists is the whole subject of this article. Encryption protects the contents of your traffic and does nothing at all for the envelope around it.

The DNS problem comes first#

Before you open a page, you look up its address. That lookup is a DNS query, and in the ordinary case it is a small, unencrypted packet sent over UDP port 53.

The query contains the name you asked for. RFC 1035 defines the message format: a DNS query carries the name being resolved in its question section. Nothing about it is confidential, because nothing about it was designed to be.

So before any TLS is involved, your ISP has already been told the name of the site. When you then connect, the same name usually appears again, inside the TLS handshake.

That repetition is not an accident of implementation. It is the reason www.wikipedia.org shows up on a network operator’s logs.

The TLS handshake has your name in it, too#

When you connect to an HTTPS site, the client sends a ClientHello to start the handshake. In the widely deployed case, that message includes a server name indication extension, the server_name extension defined in RFC 6066, which carries the hostname you are trying to reach.

The ClientHello is not encrypted. TLS 1.3 (RFC 8446) encrypts everything after the ServerHello, which improves the protocol considerably and leaves the ClientHello exactly where it was, in cleartext on the wire.

This is the single most useful fact for understanding censorship, and the same fact explains why filtering by domain name works at all: an observer on the path can read the destination hostname without breaking anything.

Encrypted Client Hello exists to close this specific gap, and it is implemented in a growing number of browsers. Deployment is still partial, and where it exists it degrades gracefully rather than failing, since servers that do not support it simply see no name, which makes the connection look more anonymous to a filter, not less.

What is left after you strip the contents#

Remove the payload and you are left with metadata, and metadata is not a consolation prize. The Tor Project states the problem plainly in its own overview: even if you encrypt the data payload of your communications, traffic analysis still reveals a great deal, because it focuses on the header, which discloses source, destination, size, and timing.

Work through it on a single evening. A list of the sites someone visited, reconstructed from DNS lookups plus destination IPs, produces a very good profile: health searches next to pharmacy sites, job boards next to a job application, one unfamiliar domain visited repeatedly at unusual hours.

This is why the IETF published RFC 7258, Pervasive Monitoring is an Attack, as an Informational RFC in 2014. No deployment is possible or intended. It is a formal statement that treating link metadata as free is a design error.

Encrypted DNS moves the observer, it does not remove one#

If DNS lookups are the problem, the obvious fix is to encrypt them. Two standards do this: DNS over TLS (RFC 7858) and DNS over HTTPS (RFC 8484). Both are real, both are widely supported, and both are worth enabling.

They also do something specific that is easy to misread. Encrypting DNS hides the lookup from the network between you and the resolver. It does not hide the lookup from the resolver.

The name you asked for still arrives at whichever server resolves it, in plaintext on that resolver’s side. In exchange you hide the lookup from your ISP and from the local network, including, usefully, from other people on the same café or campus Wi-Fi.

The gain is real. What moved is the observer, and the observer is now a single resolver rather than every router on the path.

Common misconceptions#

“Nobody can see anything, it’s HTTPS.” The contents, yes. The destination name and the metadata, no. The difference between the two is the entire subject of censorship resistance.

“My ISP can’t see my searches.” Searching on a search engine is one HTTPS request to one hostname. Your ISP learns the hostname. It does not learn the query terms, which are in the encrypted part, but it learns where you went.

“Incognito mode hides me.” Incognito mode changes what your browser stores and shares with other sites. It changes nothing about what leaves your router. Your ISP is upstream of the browser and does not care what the browser is doing.

“A VPN makes me invisible.” It makes the contents invisible to the local network and changes the address that destinations see. It does not remove metadata from the connection between you and the VPN server, and it introduces a party who can see both ends of your traffic. That is a trade, not a disappearance, and the next article in the path explains it in full.

“Nobody is interested in me anyway.” Possible, and irrelevant to the design question. The people who build these systems did not conclude that nobody would ever look; they concluded that the cost of being wrong is high enough to design against it.

What this means in practice#

Read your own ISP’s privacy policy before drawing conclusions from this article. Policies vary enormously, and in a number of countries operators are required to retain certain records for law enforcement. What matters for your own threat is that you know which of those rules apply to you.

The practical summary:

• Assume your ISP knows which sites you visit and when. This is a reasonable default even if the policy promises otherwise.
• Assume the contents of HTTPS traffic stay unread. This is a safe assumption, because it is a property of the protocol rather than a promise by an operator.
• Enable encrypted DNS. It moves the DNS observer from your network to a single resolver.
• Know what you are buying when you tunnel. A tunnel changes who can see the metadata: from your network to the tunnel operator.

Related#

• Privacy vs Anonymity — why hiding your destination is not the same as hiding who you are
• What Is a VPN? — what a tunnel actually changes, and what it leaves alone
• What Is Internet Censorship? — what a network does with what it can already see

Short answer#

A VPN protocol has to answer four separate questions:

1. Transport: what carries the tunnel? UDP, TCP, or something shaped like web traffic
2. Authentication: how do the two ends recognise each other?
3. Encryption: what protects the payload?
4. Framing: what does the encrypted stream look like from the outside?

Most protocols answer the first three competently. The fourth is where they differ from each other, and it is the only one a censor can act on without breaking the cryptography.

The families#

Layer-3 IP tunnels#

The tunnel carries IP packets, and your operating system routes into it as if it were a network interface. This is the traditional definition of a VPN.

IPsec with IKEv2 is the standardised one, built into operating systems, and designed for site-to-site networks as much as for individuals.

WireGuard takes a modern line on the same idea: a layer-3 tunnel over UDP, with a deliberately small codebase and a fixed set of cryptographic primitives.

OpenVPN sits between these two families, because it runs its layer-2 or layer-3 tunnel inside TLS. Its own documentation describes it as a full-featured SSL VPN implementing OSI layer 2 or 3 extension using the standard TLS protocol. That flexibility lets it run over TCP or UDP, and through NAT, and it also fixes its outer layer as TLS, which is the most closely inspected protocol on the internet.

Proxy protocols#

A proxy protocol is not a network tunnel but a forwarding format. Your application hands it a destination, and it opens the connection.

Shadowsocks is an encrypted SOCKS proxy. It was designed to be simple and unremarkable, and it became one of the most widely used circumvention tools in the world, which also made it one of the most studied. Research presented at ACM IMC in 2020 documented exactly how a national filtering system identified it.

VLESS is a much thinner protocol, described by its own documentation as a stateless lightweight transport that bridges client and server. It delegates all encryption to whatever transport carries it.

Disguised transports#

The third family does not replace a protocol; it wraps one in something already common on the internet. This is where the current design work sits, because it is the only family whose answer to question four is “make me look like something else”.

How they compare#

The last two rows are the ones that matter on a restricted network, and they are the reason the newest family exists.

Why the protocol is a censorship question#

Everything in the previous section is invisible to a censor, because all of it happens inside the tunnel. The one thing that is not hidden is the tunnel itself.

This is not a theoretical concern. A 2024 paper in Communications of the ACM demonstrated that OpenVPN traffic is statistically distinguishable and can be classified. The general finding is worse than the specific one: encrypted VPN traffic carries a signature in its packet sizes and timing that a classifier can learn.

So the protocol choices divide cleanly into two questions:

• If nobody is trying to block you, pick on operational grounds. WireGuard is small and fast; OpenVPN is flexible and ubiquitous; IKEv2 needs no extra software.
• If somebody is trying to block you, the wire appearance decides, and that is where VLESS with REALITY is a different proposition from the rest. The project’s own documentation is explicit that REALITY removes server-side TLS fingerprint characteristics while keeping forward secrecy.

Neither question has a single right answer, which is why both exist.

Choosing#

Some rules that hold regardless of what else you care about:

• Prefer a protocol with a small surface. Fewer options means fewer distinguishable behaviours. WireGuard’s design premise is that you cannot extend it, which is the point.
• Check the transport, not just the protocol. A good protocol on a bad transport inherits the transport’s problems.
• Treat “undetectable” as unproven. Any protocol whose documentation promises invisibility is making a claim about an adversary’s capabilities. Ask what was measured, against what, and by whom. Atlas treats such claims as claims.
• Prefer boring to clever, unless you have a reason. The oldest advice in this field remains correct for most people most of the time.

Common misconceptions#

“The protocol decides the security.” It decides part of it. Client authentication, endpoint configuration, patching, and who can reach the server all matter as much, and none of them are in the specification.

“OpenVPN is insecure.” The claim in the literature is specific: that its traffic is distinguishable, not that its cryptography is broken. Fingerprintability and cryptographic weakness are different problems with different fixes.

“UDP is faster than TCP.” Usually, and not always. UDP has no congestion control, so a WireGuard connection over a lossy path can be worse than a TCP-based tunnel that adapts.

“Any protocol will work if I wrap it in TLS.” Wrapping one encrypted protocol inside another produces a recognisable structure, and the Xray project warns about exactly this: combining REALITY with other proxy protocols produces clear TLS-in-TLS characteristics that have already been targeted.

“Newer is better.” WireGuard is newer than OpenVPN and much simpler; that is a real advantage in some ways and a real limitation in others, since it deliberately omits anything that would allow the protocol to grow.

Related#

• What Is WireGuard? — the smallest, most opinionated design
• What Is VLESS? — the thinnest protocol in the set
• What Is REALITY? — the transport layer that answers question four
• What Is Deep Packet Inspection? — why the wire appearance matters
• What Is Hysteria2? — a QUIC proxy that bets on loss and throughput instead of camouflage

Short answer#

A VPN changes three things and leaves the rest of the problem alone.

It hides the contents of your traffic from the network between you and the server.

Your destination is hidden from that network too, which sees one remote address instead of every site you visit.

Every site you reach sees a different IP address, because the destination sees the server, not you.

What it does not change: what websites know about you through your accounts, what you do on the connection, whether the tunnel is visible to a network that is looking for tunnel traffic, and the fact that one party, whoever operates the server, can see both ends.

The mechanism#

Three parts, and the middle one is the point.

A client on your device captures the traffic you want protected.

A tunnel carries it to the server. It is encrypted end to end, so nobody in between can read it or change it without the change being detected. WireGuard, for example, sends all of its packets over UDP and derives session keys from the Noise IK handshake, with an optional pre-shared key mixed in. OpenVPN takes the same overall shape, running its layer 3 tunnel over TLS.

A server decrypts it, then originates a fresh connection to the destination on your behalf.

The consequence is that your ISP, the café router, or a national network sees this:

you  ⟶  encrypted tunnel  ⟶  VPN server  ⟶  websites

instead of this:

you  ⟶  wikipedia.org, github.com, your bank, …

The metadata does not disappear; it moves to the far end of the tunnel. That is what a tunnel is, not a flaw in the design.

What a VPN changes#

Your address, as seen by destinations: every site receives the server’s address. Two consequences follow, and they point in opposite directions. Geolocation and IP-based rate limits stop working on you, and services that flag or block known VPN ranges start flagging you.

The contents of your traffic, from anyone on the local path.

Your destination list, from anyone on the local path.

Traffic from the local network to you, in one direction: replies arrive from one address instead of many, which removes a mapping you might rather not have exposed.

What a VPN does not change#

Your accounts. You are logged in to your email, your bank, your social network. Every one of those services identifies you exactly as it did before. This is the point at which most “anonymous VPN” claims stop.

The site you are visiting, once you get there. The destination receives a request from the tunnel; everything about how you behave inside it is unchanged.

What is in the tunnel. A tunnel protects the transport. It does not make a malicious download safe, and it does not make a convincing phishing page less convincing.

Whether anyone can tell there is a tunnel. A VPN is a recognisable thing on the wire. Networks that are looking for VPN traffic can find it, which is a topic of its own and the reason censorship-resistant protocols exist.

Whether the tunnel operator is trustworthy. A tunnel that hides you from your ISP necessarily exposes you to the operator. There is no configuration that removes this, because the operator has to be able to read the data to forward it.

Who can still see what#

Read that table as a relocation of risk rather than a reduction. The row that matters is the third one.

Self-hosted or commercial#

This is the decision with the largest effect on that table, and it is not primarily about price.

Self-hosted means you operate the endpoint. Nobody sits between you and the exit. Nobody has your metadata, because there is no second party to hold it. In exchange, the server is yours to patch, monitor, place in a jurisdiction you trust, and keep out of abuse blacklists, which are the operational tax most people underestimate, because one complaint about your server can cost you an address range.

Commercial means someone else runs the infrastructure, keeps it patched, holds many locations, and handles the operational work. In exchange you are trusting an organisation with your metadata, and the strength of that trust depends on its jurisdiction, its logging policy, and whether anyone has independently checked.

There is a third option, between them: paying for infrastructure you operate yourself, hosted with a provider that does not know who is using it. It removes the commercial logging question without taking on server administration.

Common misconceptions#

“A VPN makes me anonymous.” It does not. It gives you privacy from your network, and it introduces a party who can see both ends. Privacy versus anonymity covers that difference properly, and VPN, proxy or Tor puts the alternatives side by side.

“A VPN is just encryption.” The encryption is how the tunnel is protected, but the tunnel is what changes the shape of your traffic. Anyone who can see that you have a persistent encrypted connection to a single address already learns a great deal, because metadata survives inside the tunnel too.

“It hides me from my government.” It hides your destinations from your network. Depending on where the server is and who runs it, the destination may now be visible to a different government, and to the operator.

“Free VPNs are fine because I have nothing to hide.” A free service has costs to recover, and the cheapest currency is your metadata. Nothing here says every free VPN is dishonest. The reason to ask is what the operator is selling and how you know.

“More locations is always better.” Location matters for latency and for reaching a service that blocks certain ranges. It does not change the trust question, and a server in a friendly country with an operator under a hostile jurisdiction is not a contradiction the number of locations resolves.

Related#

• What Does Your ISP See? — the list this article is answering
• Privacy vs Anonymity — what a tunnel gives you, and what it does not
• VPN vs Proxy vs Tor — how a tunnel compares with the other two tools
• What Is Internet Censorship? — the reason a tunnel stops being enough
• What Is a VPN Protocol? — the specification behind the tunnel in this article

The most useful thing to know is that censorship is not one switch. It is a stack, and it is defeated or worked around one layer at a time.

Short answer#

Censorship operates at five layers, and they can be used independently:

1. DNS — control which names resolve at all
2. Transport — block the addresses and ports that carry traffic
3. Session — read the hostname inside the TLS handshake and drop the connection
4. Payload — inspect the shape of the encrypted traffic and classify what tool produced it
5. Active — send your own probe to a server and see how it answers

Each layer is cheaper and more effective than the one above it. An operator who can block your server’s address does not need to inspect anything. An operator who cannot block your address can often still read the hostname. Only the last two layers require actually looking at your traffic, and they are the most expensive to run.

The five layers#

DNS#

The first and oldest layer. The network answers name lookups itself, and answers them with something false, or refuses to answer. You do not need to see inside anything to do this, because the name is already in the clear.

Because it is the cheapest layer, it is also the most common, and because it fails soft, it produces the confusing experience of “the site is down” when in fact the name is being lied about. Switching to encrypted DNS defeats this layer specifically, and only this layer, while moving the observation to whoever operates the resolver.

Transport#

IP and port blocking: refuse to carry traffic to a given address, or to a given address and port combination. No inspection at all, and it works against a known server address immediately.

This is the layer that makes IP addresses precious. A server that is discovered, reported, and blocked is gone, and the operational answer is rotation: many addresses, changing. That dynamic is the reason address management has become a discipline of its own rather than an afterthought.

Session#

TLS hides the contents of a connection, but the name of the server is usually still sent in cleartext in the handshake. Filtering on it requires no decryption at all.

This is why encrypted DNS alone is not enough, and why the hostname keeps appearing even after everything else is protected. It is also the cheapest layer that still lets an operator make a selective decision rather than an all-or-nothing one, which is what makes it the technique most often described as the modern censorship workhorse.

Payload#

When names and addresses are no longer enough, an operator inspects the traffic itself. Deep packet inspection is the general name for this, and it is the layer where encrypted traffic becomes statistically interesting rather than opaque.

This is the most computationally expensive layer, because it means classifying traffic that was specifically designed to look like noise.

Active#

The layer that changes the character of the problem. Instead of waiting for you to send traffic, the operator sends its own to your server, deliberately, to see how it answers.

Research published at ACM Internet Measurement Conference described this against Tor, SSH, and VPN protocols, and found something operationally surprising: the systems triggering active probes appeared to be distinct from the main censorship infrastructure, and blocked by address and port together rather than by address alone. A single blocking layer cannot neutralise it, because the probes arrive from directions you have no reason to expect.

Why it is built this way#

The layers are ordered by cost, and that ordering is the design. Blocking an address costs nothing and catches most users. Reading hostnames costs very little and catches users with new addresses. Classifying encrypted traffic is expensive. Probing servers actively is expensive and exposes the censor’s own infrastructure.

A mature censorship apparatus deploys all five, and the pressure it applies grows with each layer. This is the reason a tool can work for months and then stop working with no change to the tool: something moved down the stack.

How much of it there is#

Censorship is not only a matter of national infrastructure. Two independent bodies document its extent, and both make the point that the number is large and the trend is upward.

Access Now and the #KeepItOn coalition maintain the Shutdowns Tracker Optimization Project dataset, the most complete record of deliberate internet shutdowns since 2016. Their 2025 report, published on 31 March 2026, recorded at least 313 shutdowns in 52 countries, the highest annual total since the dataset began, and revised the 2024 figure upward from 296 to 304. Those totals are kept current, so an earlier figure will usually differ from the one a later report prints.

Shutdowns are the crude end of the spectrum: connectivity removed entirely. The subtler end is filtering, and here measurement research has found more than intuition suggests. The GFWeb study presented at USENIX Security 2024 found that a single national filtering apparatus maintains separate blocklists for DNS, HTTP and HTTPS, and averages hundreds of thousands of newly blocked domains per month across those three middleboxes. It also found overblocking, in which matches run wider than the intended target, and documented a case where a rule blocking a specific organisation’s domain also caught everything beneath it.

Freedom House’s annual Freedom on the Net assessment covers 72 countries and tracks what it calls key internet controls: obstacles to access, deliberate blocking of applications and technologies, and legal or regulatory pressure on providers.

Censorship vs surveillance#

They are different capabilities, and the difference is practical rather than semantic.

Censorship prevents. It acts on the network, decides whether a connection may exist, and can do so without ever reading the traffic. DNS filtering is censorship with zero content awareness: the operator lies about an address and learns nothing about what you would have fetched.

Surveillance observes. It records what happens, generally with no power to stop it. An encrypted connection that is being watched is still being watched: the observer records addresses, timings and volumes, which is often enough to answer the question they actually had.

The two are routinely combined, because an apparatus built for one sits close to an apparatus for the other. But they fail independently and they fail differently:

The practical consequence: a censorship-resistant protocol protects you from being stopped. It does nothing about being recorded. Confusing the two is how people end up with a tunnel and no privacy, or with strong metadata hygiene and a connection that will not open.

What it means for someone using a tunnel#

Blocking differs from detection. A network can know you are tunnelling and be unable to stop it. It can also stop a specific protocol without knowing what it is. Both happen.

The failure you experience is specific. A connection that times out on port 443, a name that resolves to the wrong address, and a server that works until it does not, are three different problems with three different fixes. Naming the layer is most of the diagnosis.

Encryption is necessary and not sufficient. Every layer above the first is defeated by encryption, and every layer below it, the DNS layer in particular, is defeated by not encrypting DNS. A tool that handles the first without the second is a tool with a hole in it.

Rotation is infrastructure. For anyone operating a server, the pattern above means that address management decides whether an incident is an outage or a Tuesday.

Common misconceptions#

“Blocked means deleted.” Usually it means hidden, not removed. A domain blocked at DNS still exists, and may be reachable by address if you already know it, which is why the first thing to try with a blocked name is a different way to resolve it.

“Encryption defeats censorship.” It defeats the payload and session layers, and does nothing at all for name resolution or address blocking.

“If a site loads, censorship is not happening.” The interesting filtering is selective and cheap. You cannot infer the absence of censorship from one working page.

“Censorship is only about politics.” Filtering decisions are made constantly and mostly automatically, including against content nobody decided to target. Overblocking is a documented and measurable effect, not a rare edge case.

“Censorship and surveillance are the same thing.” They are different capabilities, and conflating them leads to tools chosen for the wrong job. The next section separates them.

Related#

• What Is Deep Packet Inspection? — the payload layer, in detail
• What Does Your ISP See? — what your network knows before anyone blocks anything
• What Is a VPN Protocol? — and why protocol choice is a censorship question
• Why a VPN Can Work Today and Fail Tomorrow — the five-layer model read against a documented failure record
• What Makes a VPN Resistant to Censorship? — the six-layer stack, from protocol to operations

REALITY is a transport-security mechanism for Xray that removes the need for a proxy server to have its own domain and its own certificate. Instead of proving its identity with credentials of its own, a REALITY server proves it by presenting the handshake of a real, unrelated website. Any client that is not authorised is passed through to that website.

The project’s own summary is that it replaces the use of TLS, eliminating the detectable server-side TLS fingerprint while maintaining forward secrecy.

What problem it solves#

A proxy server has an identity problem. A conventional TLS server needs a certificate for a domain it controls. That domain is published, resolvable, and either hosted on the same address as the proxy or discoverably associated with it. An operator who wants to find your proxy starts with the domain in the certificate.

A server fingerprint problem sits behind that one. Even when the cryptography is correct, a server’s implementation choices are not invisible. Extension ordering, cipher preferences, session ticket behaviour and similar details differ between implementations and can be measured on the first connection, before any authentication has happened. If a filter can tell that a TLS server on a given address is not the site it claims to be, the camouflage fails on the first probe.

REALITY’s answer to both is the same: do not have an identity. Borrow one.

How it works, at the depth that matters#

It only modifies TLS. The project’s documentation states this plainly, and the server-side implementation is a fork of Go’s standard crypto/tls package. This is why REALITY is specific to TLS-like transports: the current documentation lists RAW, XHTTP and gRPC as the transports it can be used with.

The client proves itself inside the ClientHello. A client holds the server’s public key and a short ID, an identifier the server keeps a list of. It builds its ClientHello so that it carries a value the server can decrypt with its private key and verify: the short ID and a timestamp inside the session ID, sealed with a key derived from the exchange. The server decrypts it, checks the short ID against its list and the timestamp against its allowed clock difference.

The official documentation notes that on the client side this mainly requires handling around a fully random session ID and custom certificate verification.

An authorised client gets a temporary certificate. When the short ID and timestamp check out, the server issues what the project calls a temporary trusted certificate, signed by a temporary authentication key the client can verify. Forward secrecy is preserved because the session keys come from the handshake itself, not from the certificate.

Anyone else gets the real website. This is the part that matters for resistance to probing. For camouflage reasons, Xray directly forwards traffic that fails authentication to the target, and the server completes the handshake with the real site before passing the response back. A prober receives a genuine certificate, issued by a genuine certificate authority, for the site it asked for.

The client must also look ordinary. REALITY requires a fingerprint setting on the client, and the documentation describes it as using a TLS library to emulate a browser’s client fingerprint. Without this, the client side carries its own distinctive signature and the server-side work is wasted. This is a genuine two-sided requirement, and it is the part most often skipped.

Server names must be genuine. The allowed serverNames are the hostnames the server will accept, and they must match the target’s certificate, because that is the certificate a non-authorised client will see.

What it explicitly does not do#

• It does not hide that your address runs a server. The certificate belongs to the target; the address does not. Anyone who knows the address can compare the two.
• It does not hide traffic volume or duration. A single long-lived connection to one address is still one connection to one address.
• It is not available for every transport. The documentation restricts it to RAW, XHTTP and gRPC.
• It does not remove the need for a client-side proxy protocol. VLESS supplies that. REALITY secures and disguises; it does not forward.
• It introduces a dependency. The target site is now part of your system. Its behaviour, its address range, and its popularity all become operational concerns.
• It has a documented operational hazard. The documentation warns that if the target’s address is shared, as with a site behind a large CDN, your server effectively becomes a port forwarder for that CDN, and can be abused after scanning. Choose a target accordingly.

How a censor sees it#

To an active prober: almost nothing. A prober connecting to the address receives a genuine TLS session with a genuine certificate for a real, popular site. There is no mismatch to report and no server fingerprint to compare against a known implementation. The project’s documentation is careful to state that a REALITY client receives the real certificate in three situations: the server rejects the handshake, an intermediary redirects it, or there is a man-in-the-middle. In all three the observation is indistinguishable from ordinary browsing.

To a passive observer: one TLS connection. This is the real residual exposure, and it is worth stating without hedging. What remains is statistical: how long the connection lasts, how much data it carries, whether the pattern resembles browsing to that site or resembles something else entirely. A filter that models expected traffic profiles for a given destination can still notice an outlier. Doing so reliably, against a varied population of targets, is an open research question rather than a solved problem, and Atlas treats it as one, rather than as “REALITY is undetectable”.

When it fits#

Good fit: you operate the server; you can choose a target that is popular, stable, on its own address and already TLS on 443; you run an Xray-based client; you understand that a misconfiguration on either side removes the benefit.

Poor fit: you need something to work over UDP as well; you want a protocol you can reason about entirely from its specification; you are unwilling to run a client that deliberately imitates a browser, or to depend on a third-party website’s behaviour.

Related#

• What Is VLESS? — the proxy core this transport is normally paired with
• What Is Deep Packet Inspection? — the classification problem behind the design
• What Is a VPN Protocol? — how this fits among the alternatives
• What Is Hysteria2? — the other answer: look like ordinary HTTP/3 rather than borrow a site

VLESS is a stateless, lightweight proxy protocol that carries requests between an Xray client and server. Its own documentation describes it in one line: a protocol with no state and no encryption of its own, whose entire job is to move an address, a port and a payload from one end to the other.

What problem it solves#

Server state. The protocol it was built to replace, VMess, keeps per-session state and generates per-request randomness on the server. That costs memory, costs CPU under load, and makes adding or removing users awkward. VLESS’s design note is explicit that the earlier “response authentication” mechanism was dropped in favour of a leading protocol-version byte, which removed the need to generate pseudo-random numbers entirely. A stateless server validates a UUID and forwards.

A protocol that encrypts, then wraps its own encryption in TLS, produces a recognisable structure: TLS inside TLS. Because the layers are visible to anyone reading the byte stream, this is not a weakness that better parameters fix. The Xray project’s own guidance warns about it: pairing REALITY with proxy protocols other than XTLS produces clear TLS-in-TLS characteristics that have already been targeted.

VLESS removes the inner layer instead of trying to disguise it.

How it works, at the depth that matters#

A request is a compact, fixed-layout frame:

1 byte    protocol version
16 bytes  UUID
1 byte    length of the addons section
M bytes   addons, protobuf-encoded, optional
1 byte    command
2 bytes   port
1 byte    address type
S bytes   address
X bytes   request data

The response has the same shape in miniature: a protocol version, an optional addons section, and the response data.

Three properties follow from that design.

It is a protocol with no cryptography. Everything security-relevant is delegated to the transport carrying it. Used over plain TCP with nothing else, VLESS is an unencrypted forwarding format. That is the design rather than a flaw, and it is why VLESS is always described together with a transport.

The server holds no session table. Adding a user means adding a UUID; removing one means removing it. The project’s documentation notes that this lets a server handle very large numbers of users with fast verification, and that changes take effect immediately.

Versioning happens at the front. The first byte is a version, so the framing can evolve without a separate negotiation, and a server can support more than one version at once.

XTLS Vision is the common pairing: VLESS is commonly paired with a flow-control mode called XTLS Vision. It is optional, and it is a performance feature: the project’s documentation describes it as avoiding redundant copying of already-encrypted data, with the largest gains on TLS transports.

What it explicitly does not do#

• No encryption. On its own it protects nothing.
• No obfuscation. It does not try to look like anything. It aims to look like nothing at all, which is a different strategy.
• No certificate handling, no key exchange, no replay protection. All of that belongs to the transport.
• No anonymity. The exit server still sees the origin, and the destination still sees the exit.
• No standalone use. VLESS without a secure transport is not a VPN, however the configuration file is written.

How a censor sees it#

On its own: nothing to see. A bare VLESS stream is a small, regular, unencrypted framing format with a stable header. Anyone can see what it is, which is why nobody uses it that way.

Inside a TLS transport: TLS. If VLESS runs inside ordinary TLS, what a censor sees is a TLS session. Whether that session is distinguishable depends on the transport rather than on VLESS, and on the specific weakness the project warns about, where a proxied protocol inside TLS leaves a nested structure behind.

Inside REALITY: the real site’s handshake. This is the pairing REALITY was designed for. Because VLESS contributes no encryption of its own, the transport’s characteristics are the whole of what is visible, and REALITY makes those characteristics those of a genuine site.

When it fits#

Good fit: you are running Xray on both ends; you want a proxy core with minimal server state; you have chosen a transport that handles security, and the pairing is the design, not a workaround.

Poor fit: you want a single self-contained protocol that secures the connection on its own; you want a protocol that resists detection by itself; you prefer fewer moving parts than an Xray deployment provides.

Related#

• What Is REALITY? — the transport VLESS is normally paired with
• What Is a VPN Protocol? — how a protocol with no cryptography fits into the set
• What Is WireGuard? — the opposite approach: all the cryptography, and no proxy core
• What Is Hysteria2? — the QUIC option: encryption from the transport, plus its own congestion control

WireGuard is a layer-3 network tunnel that runs over UDP, using a fixed set of modern cryptographic primitives and a handshake taken from the Noise Protocol Framework. It is deliberately small: by the authors’ own comparison in their talks, around four thousand lines of code, against roughly a hundred thousand for OpenVPN and several hundred thousand for IPsec.

What problem it solves#

Two problems at once, and they are related.

Complexity. Long-lived protocols accumulate options: version negotiation, cipher suites, plugin systems, compatibility shims. Every option is a place where implementations disagree and bugs live. WireGuard’s response is to remove the options. Its protocol name is a contract: Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s names every primitive in use, and there is nothing else to negotiate.

Auditability is the reason a small protocol matters: one can be read. The cryptography has been examined formally and by peer-reviewed analysis: Dowling and Paterson’s A Cryptographic Analysis of the WireGuard Protocol proved key indistinguishability and authentication properties for the key exchange, under standard assumptions, and documented the reasoning around key-compromise impersonation attacks.

How it works, at the depth that matters#

Primitives. From the project’s own protocol description: Curve25519 for the Diffie-Hellman operations, ChaCha20 authenticated with Poly1305 following RFC 7539 for the symmetric layer, BLAKE2s for hashing and keyed hashing, SipHash24 for hash table keys, and HKDF for key derivation.

The handshake uses the Noise IK pattern, which authenticates both parties in one round trip while hiding their identities from a passive observer, and rekeys regularly to maintain perfect forward secrecy. The project describes the handshake as occurring every few minutes specifically so that keys rotate.

Transport is UDP for every packet. There is no TCP mode and no fallback.

Denial of service is addressed directly. Because any UDP endpoint can be made to do work, WireGuard adds a cookie mechanism: a returning client proves it has seen a recent handshake before the server does expensive work. The formal-verification paper describes this cookie MAC system as one of the four mechanisms the protocol is built from, alongside the key exchange and the timer state machine.

An optional pre-shared key can be mixed into the public-key cryptography. The project documents this as being useful if an additional layer of symmetric protection is wanted.

Timestamps are embedded too. WireGuard puts TAI64N timestamps in its data packets, which is what lets it discard stale packets cheaply and recognise replay.

What it explicitly does not do#

• No cipher agility. You cannot add a cipher. The protocol’s fixed primitive set is a deliberate security decision and a deliberate limitation.
• No TCP fallback. If UDP is blocked or heavily throttled, WireGuard has no answer. This is the single most common practical failure.
• No built-in obfuscation. Nothing in the protocol tries to hide that it is a tunnel.
• No dynamic users. Membership is a configuration file. There is no protocol-level mechanism for adding or removing a peer at runtime.
• No resistance to blocking. WireGuard was not designed against censorship, and there is no claim that it was.

How a censor sees it#

Poorly disguised, and honestly so.

A WireGuard connection is a UDP flow to a single address and port that begins with a recognisable handshake and then carries steady traffic. UDP is also a large share of ordinary internet traffic, so it is not unusual on its own. A fixed peer address with sustained bidirectional UDP is still a usable signature, and WireGuard provides no mechanism to vary it.

There is a second, subtler exposure that is not WireGuard’s fault and is worth understanding anyway: a WireGuard tunnel has a characteristic packet size distribution, because it encapsulates inner IP packets and adds its own framing. That is the same class of weakness documented for OpenVPN.

When it fits#

Good fit: you want the simplest thing that is well audited and fast; you are on a network that does not block UDP; you control your own server or trust your provider to run it properly; you value a small code surface.

Poor fit: UDP is blocked or throttled where you are; you need to appear as ordinary web traffic; you need credentials that change without touching configuration.

Related#

• What Is a VPN Protocol? — where WireGuard sits among the alternatives
• What Is Deep Packet Inspection? — the classification problem every protocol shares
• What Is REALITY? — the opposite design bet: maximal camouflage, no negotiation at all
• What Is VLESS? — the same goal reached by removing the cryptography instead
• Obfuscation vs Encryption — the axis this protocol deliberately leaves open
• What Is Hysteria2? — the same UDP bet, with congestion control tuned for loss

It is a legitimate network tool for traffic management, malware detection and quality of service, and it is also the most capable and most expensive censorship technique. Understanding what it can and cannot see is the difference between a tunnel that works and one that does not.

Short answer#

Encrypted traffic is opaque in content but not in shape. The sizes, directions and timing of your packets still describe the application running over them, and that description is what DPI classifies on.

So DPI cannot read your messages. It does not need to. It can work out which tool produced the stream, block it, and in some cases work out who is using it.

What DPI looks at#

Traditional routing checks where a packet is going. DPI examines:

• Payload structure — byte patterns, protocol signatures, and the header layout of the application protocol
• Packet size distribution — how large each packet is, and how that differs between application types
• Inter-arrival timing — how long packets take to arrive, and the rhythm of bursts
• Direction and volume — how much flows each way, and when it stops
• Quic, TLS and other record framing — the outer shape imposed by the transport in use

The payload items matter most for plaintext and poorly designed protocols. For a modern encrypted tunnel, the last three do the work, and they work surprisingly well.

What it has actually managed to do#

The evidence here is unusually good, because researchers have been able to measure it directly rather than infer it.

An encrypted proxy tool was identified from its first packet. Research presented at the ACM Internet Measurement Conference in 2020 investigated how a national filtering system detected and blocked Shadowsocks, a widely used encrypted proxy. The finding was that the filter used the length and entropy of the first data packet in each connection to identify probable proxy traffic, and once suspicious, followed up by sending the connection to a set of probes. No decryption, no payload access, no deep analysis of the stream.

An ordinary commercial VPN was fingerprinted. A 2024 paper in Communications of the ACM, “OpenVPN is Open to VPN Fingerprinting”, showed that OpenVPN traffic is statistically distinguishable. The general result matters more than the specific protocol: encrypted VPN traffic can be classified, and a classifier trained on one protocol’s characteristics does not need any access to the contents.

Encrypted QUIC is not a hiding place either. Work presented at USENIX Security in 2025 found that a national filtering system decrypts QUIC Initial packets at scale, applies heuristic filtering rules, and maintains a blocklist distinct from its other censorship mechanisms. This is notable because QUIC Initial packets are the part that is not supposed to be secret: the point is that the system is sophisticated enough to work with only what is legitimately visible, and to do it at volume.

The filter is then followed by probes. A 2015 IMC study described a layered process: passively notice suspicious traffic, then actively connect to the server behind it and check what it does. Its researchers found the probing systems appeared to be distinct from the main censorship infrastructure, and that blocking happened by address and port combination rather than by address alone, a detail that matters enormously to anyone rotating servers.

Why shape is so informative#

Encryption hides what you said. It cannot hide how much you said, when, or in what unit sizes, because those are properties of the transport and the network has to route it.

Concrete consequences:

• A file transfer sends long, evenly sized streams. Interactive traffic sends many small packets with pauses. The two are trivially distinguishable.
• Traffic that arrives and then goes silent for long periods has a different signature from a video stream.
• The very first packet of a connection often leaks the protocol, because protocol headers have characteristic sizes. This is precisely what the Shadowsocks measurement exploited.
• Patterns repeat. A classifier does not need to solve a single connection; it can recognise the recurring shape of a tool over hundreds of connections.

None of this requires breaking the cryptography. That is the part worth internalising: the attack surface here is not the cipher.

What DPI does not do#

• It does not read your content. Traffic protected by a correctly implemented TLS 1.3 connection is not readable by a network observer. DPI at the payload layer sees ciphertext.
• It does not work offline. Classification is statistical. A careful operator can make traffic look ordinary, and can change it when the classifier is retrained. That is a real defence, and it is why censorship resistance is an ongoing project rather than a solved problem.
• It is not one system. “DPI” describes a technique, deployed with wildly different sophistication. A small operator and a national one are not playing the same game.

Why this is where protocol design began to matter#

If you cannot hide the content, you can still work on the shape. That is the reasoning behind everything in the family of censorship-resistant protocols.

The strategies, roughly in order of how much they change the stream’s appearance:

1. Make the traffic actually resemble something common. The strongest version of this does not merely imitate a protocol, it makes the server actually behave like the thing it appears to be, so a probe cannot tell the difference.
2. Carry the tunnel inside something already allowed. Wrapping in a protocol that is indistinguishable from ordinary web traffic moves the problem from “unknown encrypted protocol” to “ordinary web traffic”.
3. Vary the packet sizes. Padding defeats a classifier that relies on size distribution, at the cost of some efficiency.
4. Rotate. Addresses and identifiers change, so a signature collected last month is stale.

These are the strategies behind Shadowsocks’ AEAD framing, behind HTTP/2 and HTTP/3 disguises, and behind the combination of VLESS with REALITY that Maronix uses. They are not equivalent in strength, and that difference is the substance of the protocol comparisons later on the Atlas Path.

Common misconceptions#

“Encrypted means invisible.” It means the contents are invisible. The envelope is still measured, and measurement has repeatedly been enough.

“DPI reads everything, so nothing helps.” It reads shapes. Shapes can be changed. The tools that work against classification are the ones that keep doing so.

“If my traffic looks like HTTPS, I’m safe.” Appearing as HTTPS is a starting condition, not a guarantee. A system can decrypt handshake-level metadata, can compare a claimed destination with the certificate actually presented, and can probe the address to see whether it really behaves like the site it claims to be.

“My VPN provider says traffic is indistinguishable.” Ask against what, measured how, and by whom. A claim without a measurement behind it is a marketing statement, and this is a page about mechanism rather than branding.

Related#

• What Is Internet Censorship? — the four other layers, of which DPI is one
• What Does Your ISP See? — what a network knows before any classification happens
• What Is a VPN Protocol? — and why the wire appearance is a design constraint
• Obfuscation vs Encryption — the two separate answers, and which one DPI is actually attacking