How Internet Censorship Circumvention Works: Protocols and Evasion Techniques

Internet censorship circumvention is the set of techniques, protocols, and tools designed to bypass state-imposed restrictions on internet access. Unlike a standard VPN, which creates an encrypted tunnel to a known endpoint using recognizable protocol handshakes, modern circumvention tools are engineered to be indistinguishable from normal traffic under deep packet inspection. The core challenge is not merely encrypting data — any VPN does that — but making the encrypted traffic look like something a censor will not block: ordinary HTTPS connections, random noise, or even HTTP/3 QUIC sessions.

This article examines the technical architecture of nation-state censorship systems, the protocols designed to evade them, and the ongoing detection/evasion arms race that has produced some of the most sophisticated applied cryptography and traffic engineering in the real world.

How Nation-State Censorship Works

Modern internet censorship is not a single technique but a layered system that operates at multiple points in the network stack. Understanding how censorship works is essential to understanding why circumvention tools are designed the way they are.

DNS Poisoning

DNS poisoning is the simplest and most widely deployed censorship technique. The censor intercepts DNS queries and returns false responses — either an NXDOMAIN (domain does not exist), a wrong IP address pointing to a block page, or simply drops the query. Because standard DNS uses unencrypted UDP on port 53, any on-path device can read and modify queries in transit.

Countermeasures like DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the query, but they require the client to reach the DoH/DoT resolver in the first place. Censors can block known resolver IPs (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1) or detect the TLS handshake to known DoH endpoints. In China, the GFW injects forged DNS responses for blocked domains before the legitimate response can arrive, and this injection works regardless of which resolver the client queries — the forged response races the real one across the network.

IP Blacklisting

IP-based blocking is straightforward: the censor maintains a list of IP addresses or prefixes that are forbidden, and drops or resets any connection to those addresses. This is implemented at the router level, often using BGP blackhole routes or ACLs on border routers. IP blocking is crude but effective against services with well-known IP ranges. It is less effective against services hosted on shared infrastructure like CDNs, where blocking an IP would collaterally block thousands of legitimate sites.

Deep Packet Inspection (DPI)

DPI is the most sophisticated censorship technique. Instead of looking only at IP headers and port numbers, DPI systems examine the contents of packets — the payload — to identify the protocol being used and the specific content being accessed. A DPI system can:

• Read the SNI field in a TLS ClientHello to determine which website a client is connecting to, even though the rest of the TLS connection is encrypted. This is SNI filtering.
• Identify protocol signatures — the characteristic byte patterns of VPN protocols (OpenVPN, IPsec IKE, WireGuard), Tor, or other circumvention tools.
• Detect traffic patterns — packet sizes, timing intervals, entropy levels — that distinguish encrypted tunnel traffic from regular HTTPS browsing.
• Perform active probing — connecting back to suspected proxy servers to determine if they respond in a way consistent with a circumvention tool rather than a legitimate web server.

Active Probing

Active probing is a technique where the censor does not just passively observe traffic but actively initiates connections to suspected proxy servers. If the GFW sees a connection to an IP address that looks suspicious (high entropy traffic, unusual protocol behavior), it will connect to that IP address itself and attempt to interact with whatever service is running. If the server responds in a way that reveals it is a proxy — for example, by accepting a SOCKS5 handshake or responding to a specific protocol negotiation — the IP is flagged and blocked.

This is why simply encrypting traffic is not enough. A circumvention tool must also handle unexpected connections gracefully, ideally by responding exactly as a normal web server would — serving a real webpage, presenting a valid TLS certificate, and rejecting any requests that do not contain the correct authentication credentials.

TCP Reset Injection

Rather than dropping packets silently (which causes timeouts and retransmissions), many censorship systems inject forged TCP RST (reset) packets into both sides of a connection. The client and server each receive a RST that appears to come from the other side, causing both to tear down the connection immediately. This is faster and more resource-efficient than maintaining state for dropped connections.

The Great Firewall of China: Technical Architecture

China's Great Firewall (GFW) is the most technically sophisticated internet censorship system in the world. It is not a single system but a distributed infrastructure deployed at the border between China's domestic internet and the global internet. The GFW operates at the autonomous system boundaries where Chinese ISPs — China Telecom (AS4134), China Unicom (AS4837), China Mobile (AS9808) — peer with international networks at IXPs and private interconnections.

The GFW's censorship stack operates in layers:

1. DNS injection — Forged DNS responses for blocked domains, injected at the border before legitimate responses can arrive. This affects all DNS traffic, including queries sent to overseas resolvers.
2. IP blacklisting — Known proxy, VPN, and Tor relay IP addresses are blocked via BGP blackhole or null routing at the border.
3. DPI with SNI filtering — TLS connections are inspected for blocked domain names in the SNI field. Connections to blocked SNIs receive TCP RST injections.
4. Protocol detection — OpenVPN, IPsec, WireGuard, Tor, and other protocols are detected by their handshake signatures and blocked.
5. Active probing — Suspected proxy servers are actively connected to from Chinese IP addresses. Servers that respond as proxies are blocked.
6. Traffic analysis — Statistical analysis of packet sizes, timing, and entropy to detect encrypted tunnels that do not match known protocol signatures but also do not look like normal web traffic.

The GFW is not static. It has evolved significantly over the past decade, adding new detection capabilities as circumvention tools improve. The system is believed to run on commercial DPI hardware deployed at China's international gateways, with custom software for the active probing and traffic analysis components.

Why Traditional VPNs Fail

Standard VPN protocols like OpenVPN, IPsec, and WireGuard are trivially detectable by DPI. Each has distinctive handshake patterns:

• OpenVPN begins with a specific opcode byte (0x38 for client hello in TLS mode) and follows a predictable packet exchange pattern. Even when running over TCP port 443 (disguised as HTTPS), the initial bytes do not match a TLS ClientHello.
• IPsec IKE uses UDP port 500 or 4500 and begins with identifiable header structures (the IKE SPI and version fields).
• WireGuard uses fixed message types (1, 2, 3, 4) with specific sizes (148 bytes for handshake initiation, 92 bytes for response). The message format is unique and identifiable.
• L2TP/PPTP use well-known ports and have unmistakable protocol signatures.

Even if the traffic content is encrypted, the protocol envelope — the handshake, the packet sizes, the port numbers — tells the censor exactly what it is looking at. This is why a new generation of circumvention tools was developed, designed from the ground up to be undetectable.

Shadowsocks: The First Modern Circumvention Protocol

Shadowsocks was created in 2012 by a Chinese programmer known as "clowwindy." It was designed with a single overriding goal: make proxy traffic look like random data to a DPI system. Unlike a VPN, Shadowsocks is a SOCKS5 proxy with an encrypted tunnel — it does not create a virtual network interface or modify routing tables. Instead, applications are configured to route their traffic through the Shadowsocks client, which encrypts and forwards it to a remote server.

Protocol Design

Shadowsocks takes a fundamentally different approach from VPN protocols. There is no handshake. There is no negotiation of cipher suites, no exchange of protocol version numbers, no identifiable magic bytes. The client and server share a pre-configured password and cipher, and the very first byte of every connection is encrypted payload.

The connection flow works as follows:

1. The client connects to the Shadowsocks server via TCP (or sends a UDP packet).
2. The client sends an encrypted payload containing: the target address (hostname or IP), the target port, and the actual data to forward.
3. The server decrypts the payload, extracts the target address and port, establishes a connection to the target, and forwards the data.
4. Response data is encrypted by the server and sent back to the client.

Modern Shadowsocks implementations use AEAD ciphers (Authenticated Encryption with Associated Data) — specifically chacha20-ietf-poly1305 or aes-256-gcm. Each connection generates a random salt, which is prepended to the encrypted stream. The salt combined with the pre-shared key derives per-session encryption keys via HKDF. Because the salt is random, every connection's ciphertext is unique, even if the same data is sent.

Why It Beats VPNs

To a DPI system, a Shadowsocks connection on port 443 looks like a stream of high-entropy random bytes — which is exactly what encrypted data looks like. Crucially, it does not look like a VPN handshake, a TLS ClientHello, or any other recognizable protocol. There are no magic numbers, no version fields, no cipher negotiation. The censor sees a TCP connection to an IP address on port 443, and the payload appears to be random data from the very first byte.

This is a significant improvement over VPNs, but it is not perfect. The GFW eventually learned to detect Shadowsocks through several techniques:

• Entropy analysis — Normal HTTPS traffic has a specific structure: a TLS ClientHello with recognizable fields, followed by encrypted data. A connection that is pure high-entropy data from the first byte, with no TLS handshake, is suspicious.
• Replay attacks — Earlier versions of Shadowsocks (using stream ciphers without AEAD) were vulnerable to replay attacks. The GFW could record a Shadowsocks connection and replay the first few bytes to the server. If the server accepted the replayed data, it was confirmed as a Shadowsocks server.
• Active probing — The GFW sends random data to suspected Shadowsocks servers. A real web server would respond with an HTTP error or drop the connection. A Shadowsocks server with stream ciphers would attempt to decrypt the random data, often producing an error response or behavior that differs from a web server.
• Packet length distribution — Shadowsocks connections have characteristic packet size distributions that differ from normal HTTPS, partly because SOCKS5 target addresses have predictable lengths.

The AEAD upgrade (introduced in Shadowsocks 2017/SIP003) addressed the replay vulnerability: each encrypted chunk includes a nonce and authentication tag, making replay of partial data detectable. But the fundamental issue remained — high-entropy traffic from byte one, with no protocol envelope, is itself a signal.

V2Ray and Xray: Protocol Multiplexing and TLS Camouflage

V2Ray, first released in 2015, took a more ambitious approach than Shadowsocks. Instead of a single proxy protocol, V2Ray is a platform — a modular framework that separates the proxy protocol from the transport layer, allowing arbitrary combinations. Its successor fork, Xray, extended this with performance improvements and the VLESS protocol.

VMess Protocol

V2Ray's original protocol is VMess (V2Ray Message). Unlike Shadowsocks' password-based authentication, VMess uses a UUID-based identity system. Each user has a UUID, and the client proves knowledge of this UUID through an HMAC of the current timestamp. The server validates the HMAC to authenticate the client.

VMess includes a request header containing the target address, encryption method, and command type, all encrypted with AES-128-CFB using a key derived from the user's UUID. The payload is then encrypted with the negotiated cipher. VMess supports per-connection random padding to vary packet sizes.

However, VMess has known weaknesses. Researchers demonstrated that the VMess header format has detectable patterns: the HMAC authentication uses a time-based window that can be fingerprinted, and the header structure has predictable length characteristics. The GFW exploited these weaknesses to detect VMess traffic.

VLESS Protocol

VLESS (introduced by Xray) is a stripped-down replacement for VMess. It removes VMess's built-in encryption entirely, relying instead on the transport layer (typically TLS) for security. The VLESS protocol itself is minimal: a version byte, UUID, and target address. By eliminating the custom cryptographic layer, VLESS removes the detectable patterns that plagued VMess.

The design philosophy is clear: instead of inventing a new encryption scheme (which is likely to have detectable fingerprints), use standard TLS and make the connection look identical to normal HTTPS traffic.

Transport Layers

The true power of V2Ray/Xray lies in the separation of protocol and transport. The proxy protocol (VMess or VLESS) can ride on top of multiple transport layers:

• TCP + TLS — The most common configuration. The proxy traffic is wrapped in a standard TLS connection. To a DPI system, it looks like ordinary HTTPS. The server presents a valid TLS certificate for a real domain, and the encrypted proxy traffic is indistinguishable from HTTPS page loads.
• WebSocket + TLS — The proxy protocol is carried inside a WebSocket connection, which itself runs over TLS. This allows the traffic to pass through CDNs and reverse proxies that support WebSocket forwarding. The connection performs a standard HTTP upgrade to WebSocket, then carries encrypted proxy data over the WebSocket frames.
• gRPC + TLS — Proxy traffic is encapsulated in gRPC streams over HTTP/2. This looks like ordinary gRPC API traffic to a censor, and can traverse CDNs that support gRPC.
• HTTP/2 — Direct HTTP/2 framing with TLS, using the multiplexed stream capability of HTTP/2 to carry proxy connections.

XTLS-Vision: Eliminating Double Encryption

When proxy traffic is wrapped in TLS, the data is effectively encrypted twice — once by the proxy protocol's encryption and once by the TLS transport. This double encryption wastes CPU cycles and, more importantly, creates a detectable fingerprint: the inner encrypted stream has different statistical properties than real HTTPS content.

XTLS (and its improved version, XTLS-Vision) solves this by splicing the TLS connection. When the proxy detects that the inner traffic is itself TLS (e.g., the user is browsing an HTTPS site), XTLS stops encrypting the inner TLS data and instead passes it through directly inside the outer TLS connection. Only the proxy protocol headers are encrypted by the outer TLS; the actual HTTPS payload is carried as-is.

The result is that the traffic pattern — packet sizes, timing, TLS record sizes — exactly matches what a normal HTTPS connection to the proxy server would look like if it were serving the target content directly. There is no double encryption to fingerprint.

XTLS-Vision further improved on this by addressing a subtle detection vector: during the TLS handshake of the inner connection, the proxy protocol headers create a brief window where the outer TLS records have anomalous sizes. Vision pads these records to match typical TLS handshake sizes, closing this fingerprinting gap.

Trojan: TLS-First Design

Trojan (originally "trojan-gfw") takes a radically simple approach: the proxy server is a real HTTPS web server, and proxy functionality is activated only when the client presents the correct password.

How Trojan Works

A Trojan server runs on port 443 with a valid TLS certificate for a real domain name. It serves a real website — a blog, a personal page, anything. The TLS configuration is identical to any other HTTPS server.

When a client connects, it performs a standard TLS handshake (indistinguishable from any browser). After the TLS connection is established, the client sends a Trojan request:

1. A hex-encoded SHA-224 hash of the password (56 bytes)
2. A CRLF delimiter
3. The target address and port
4. Another CRLF
5. The payload data

The server reads the first 56 bytes and checks if they match the hash of any authorized password. If they match, the connection is treated as a proxy request. If they do not match — as would happen with an active prober, a web browser, or a random connection attempt — the entire received data is forwarded to a fallback destination, typically a local web server serving the real website.

Active Probing Resistance

This fallback mechanism is the key to Trojan's active probing resistance. When the GFW connects to a suspected Trojan server:

• The TLS handshake completes normally — the server presents a valid certificate for a real domain.
• The GFW sends an HTTP request or random data.
• The server does not recognize the data as a valid Trojan password hash, so it forwards the request to the fallback web server.
• The fallback web server responds with a normal web page (HTTP 200, valid HTML).

The result is that the server behaves identically to a normal web server for any connection that does not present the correct password. There is no way for the GFW to distinguish it from a legitimate website without knowing the password.

Hysteria and Hysteria2: QUIC-Based Circumvention

Hysteria (and its successor Hysteria2) takes a different approach by building on QUIC, the UDP-based transport protocol used by HTTP/3. QUIC's built-in encryption and multiplexing make it an attractive foundation for circumvention.

Hysteria's Design

The original Hysteria protocol modified the QUIC protocol to add proxy functionality. The connection looks like a QUIC/HTTP/3 session from the outside — the initial handshake follows the QUIC format, and the encrypted payload is indistinguishable from QUIC traffic.

Hysteria2 improved on this by more closely conforming to the HTTP/3 standard. A Hysteria2 server masquerades as a genuine HTTP/3 web server:

• It completes the QUIC handshake with a valid TLS 1.3 certificate.
• Unauthenticated requests receive normal HTTP/3 responses from a fallback web page, similar to Trojan's approach.
• Authenticated requests (using a password or token) are treated as proxy traffic.

Brutal Congestion Control

A distinctive feature of Hysteria is its "Brutal" congestion control algorithm. Standard TCP and QUIC congestion control algorithms (Reno, CUBIC, BBR) reduce sending rate when they detect packet loss, interpreting loss as a signal of network congestion. But on heavily throttled or lossy international links — common when crossing the GFW — this behavior causes throughput to collapse.

Brutal ignores packet loss signals and sends at a user-specified target rate regardless of loss. If the user configures 50 Mbps and the network is dropping 30% of packets, Brutal sends at ~71 Mbps so that the received throughput after loss is approximately 50 Mbps. This is "unfriendly" to other traffic on the network (it does not back off when the network is congested), but it ensures usable speeds on heavily degraded paths.

This approach is specifically designed for the scenario where packet loss is caused by deliberate throttling rather than genuine congestion. Standard congestion control was designed for cooperative networks where loss means "slow down" — on a censored network, loss often means "we are trying to make your connection unusable," and slowing down is exactly the wrong response.

Pluggable Transports: Tor's Approach

Tor faces a unique challenge: its relay IPs are publicly listed in the directory (since clients need to find relays), making IP-based blocking trivial. Tor addresses this through bridges (unlisted relays) and pluggable transports — modular components that transform Tor traffic to look like something else.

obfs4 (Obfuscation Layer 4)

obfs4 is a look-like-nothing transport. It uses an Elligator 2 mapping to represent Curve25519 public keys as random-looking byte strings, performs an authenticated key exchange (using a pre-shared "server certificate" distributed out-of-band), and then encrypts all subsequent traffic with NaCl secretbox. The result is a byte stream that is computationally indistinguishable from random data — no recognizable protocol structure, no magic bytes, uniform byte distribution.

obfs4 also includes inter-arrival time (IAT) obfuscation, optionally randomizing the timing between packets to defeat timing-based traffic analysis.

meek

meek routes Tor traffic through major cloud platforms using domain fronting. The Tor client makes HTTPS requests to a CDN (e.g., Azure, Cloudflare) with a fronted domain in the SNI and the actual meek bridge address in the HTTP Host header. The CDN forwards the request to the meek bridge, which unwraps the Tor traffic and relays it to the Tor network.

Blocking meek requires blocking the entire CDN platform. However, domain fronting has become less viable as CDN providers (notably Google and Amazon) disabled it starting in 2018, because it was also used by malware for command-and-control communication.

Snowflake

Snowflake is Tor's most innovative transport. It uses WebRTC peer-to-peer connections provided by volunteer "snowflake proxies" running in the browsers of ordinary users. The censored client connects to a snowflake proxy via WebRTC, and the proxy forwards the traffic to a Tor bridge.

The connection uses WebRTC's ICE/DTLS/SRTP stack, making it look like a video call or other peer-to-peer media session. The rendezvous (how the client finds a snowflake proxy) uses domain-fronted HTTPS requests to a broker service. Key properties:

• Proxy IPs rotate constantly as volunteers come and go, making IP blacklisting infeasible.
• The traffic pattern resembles WebRTC media, which censors are reluctant to block because it would disable video calling.
• The broker can be reached through domain fronting or other censorship-resistant channels.

The Detection Arms Race

The relationship between censorship systems and circumvention tools is an ongoing arms race. Each generation of circumvention tool addresses the detection methods used against the previous generation, and censors respond with new techniques.

Traffic Fingerprinting

Even when a protocol's content is perfectly encrypted, the shape of the traffic reveals information. Censors analyze:

• Packet size distributions — Different protocols produce characteristic distributions of packet sizes. HTTPS browsing has a pattern (small request, large response). A SOCKS5 proxy wrapped in TLS has a different pattern.
• Inter-packet timing — The timing between packets reveals usage patterns. Interactive browsing produces bursty traffic; a streaming download produces steady traffic. A proxy server introduces additional latency that shifts timing distributions.
• TLS record sizes — TLS records have a maximum size of 16,384 bytes. Different implementations split data into records differently. A proxy that wraps encrypted data in TLS records may produce record size distributions that differ from a normal web server.
• Connection duration and volume — Circumvention connections tend to be long-lived (users keep sessions open for hours), while normal HTTPS connections tend to be shorter.

Replay Attacks

Replay attacks are a powerful detection and disruption tool. The censor records encrypted traffic from a suspected circumvention connection and replays it to the server later. If the server accepts the replayed data (e.g., processes the replayed request as valid), this confirms the server is running a proxy. It can also cause operational disruption — the server might forward the replayed request to the wrong destination or produce duplicate responses.

Countermeasures include:

• AEAD nonces — Each encrypted chunk has a unique nonce. Replaying an old chunk with a reused nonce causes decryption to fail.
• Timestamp validation — VMess validates that the timestamp in the authentication header is within a time window. Replayed requests with old timestamps are rejected.
• Replay filters — Maintaining a sliding window of recently seen salts/nonces and rejecting duplicates. Shadowsocks 2022 (SIP022) added an explicit replay filter with a bloom filter for efficient memory usage.

TLS-in-TLS Detection

When a proxy carries HTTPS traffic inside a TLS tunnel, the outer TLS records contain inner TLS records. This creates a distinctive pattern: the outer TLS record sizes are slightly larger than the inner record sizes (by the inner TLS header and encryption overhead). Researchers have shown that this size correlation can be detected statistically.

XTLS-Vision addresses this by splicing the inner TLS connection into the outer one (as described above), eliminating the nested TLS record structure. For non-TLS inner traffic (like HTTP), Vision pads the proxy protocol headers to match typical TLS record sizes.

Advanced Countermeasures

CDN-Based Relaying

Running a proxy behind a CDN like Cloudflare is one of the most effective circumvention strategies. The proxy server sits behind the CDN, and the client connects to the CDN's edge servers. The CDN forwards the connection to the proxy. Since the CDN's IP addresses are shared by millions of websites, blocking them would cause massive collateral damage.

This works best with WebSocket or gRPC transports, as CDNs readily proxy these protocols. The configuration: the proxy server has a domain name pointed to the CDN via DNS, with a valid TLS certificate provisioned by the CDN. The client connects to the CDN with the proxy's domain in the SNI (or even uses a fronted domain), upgrades to WebSocket, and the CDN relays the WebSocket frames to the proxy server.

The censor sees a standard HTTPS connection to the CDN. The SNI may show the proxy's domain (which could be blocked individually) or a fronted domain. Even if the specific domain is blocked, the user can set up a new domain, point it to the CDN, and have a working proxy within minutes.

Multiplexing

Traditional proxy configurations open a new TCP connection for each proxied connection. This creates a detectable pattern: many short-lived TCP connections to the same server, or a single long-lived connection with variable activity. Multiplexing solutions like SMUX or Yamux carry multiple proxied connections over a single underlying transport connection, reducing the number of observable connections and making traffic patterns harder to fingerprint.

Routing Rules Engine

V2Ray/Xray includes a sophisticated routing engine that directs traffic through different outbound connections based on rules. For example:

• Traffic to domestic Chinese sites goes directly (not through the proxy) to avoid the latency and suspicion of routing domestic traffic overseas.
• Traffic to blocked sites goes through the proxy.
• Traffic to ads/tracking domains is blocked.
• DNS queries use different resolvers for domestic and foreign domains.

This split-routing approach reduces the volume of traffic through the proxy (reducing cost and suspicion) and ensures that domestic services work at full speed. The routing rules are maintained as community-contributed lists (like geosite and geoip databases) that map domains and IP ranges to countries.

Iran and Russia: Different Censorship Models

While China's GFW is the most technically advanced censorship system, Iran and Russia have developed their own approaches with different characteristics.

Iran

Iran's censorship is managed by the Communications Regulatory Authority (CRA) and implemented through DPI equipment deployed at the national gateway. Iran's approach has several distinctive features:

• Protocol whitelisting — During periods of intense censorship (such as the 2022 protests), Iran has throttled or blocked all encrypted protocols that it cannot identify, effectively requiring traffic to match known, allowed protocol signatures.
• SNI-based blocking — Similar to the GFW, Iran inspects TLS SNI fields and blocks connections to blacklisted domains.
• Total internet shutdowns — Iran has repeatedly shut down international internet connectivity entirely during protests, something China has never done for the whole country. This cannot be circumvented by any protocol — if the physical/BGP connectivity is severed, no tunnel can bridge it.
• Throttling — Rather than blocking protocols outright, Iran often throttles them to unusable speeds. International bandwidth is severely restricted, making even successful circumvention painfully slow.

Iran's censorship is generally less technically sophisticated than China's but more aggressive in its willingness to cause collateral damage (blocking entire protocols, shutting down the internet entirely).

Russia

Russia's censorship infrastructure, managed by Roskomnadzor and implemented through the TSPU (Technical Means for Counteracting Threats) system, has evolved significantly since 2017. TSPU boxes are DPI devices deployed at ISP networks throughout Russia.

• DPI-based blocking — The TSPU system performs deep packet inspection and can block specific protocols or domains.
• VPN blocking — Russia has progressively blocked VPN protocols, including OpenVPN, WireGuard, and IPsec. The blocking is not always consistent — it varies by region and ISP.
• Throttling rather than blocking — Russia has famously throttled Twitter rather than blocking it outright, reducing speeds to make the service unusable without technically blocking it.
• Decentralized enforcement — Unlike China's centralized GFW at the border, Russia's DPI is distributed across ISPs, leading to inconsistent blocking behavior.
• ECH/ESNI blocking — Russia blocks TLS connections carrying the Encrypted Client Hello extension, forcing clients to fall back to plaintext SNI.

Russia's system is less effective than China's at blocking sophisticated circumvention tools, partly because the decentralized deployment makes it harder to maintain consistent, up-to-date blocking rules across all ISPs.

The Current State of the Art

As of 2025-2026, the most effective circumvention configurations combine several techniques:

• VLESS + XTLS-Vision + Reality — Xray's "Reality" feature eliminates the need for a real domain and certificate. The server impersonates another server's TLS fingerprint, stealing its certificate during the handshake (using a technique similar to TLS server name spoofing). The client verifies the server using a short ID and public key pair rather than a certificate. This makes setup easier (no domain registration needed) while maintaining the same traffic appearance as a real HTTPS server.
• Hysteria2 behind CDN — For users with access to QUIC-capable CDNs, Hysteria2's QUIC-based transport combined with Brutal congestion control provides high throughput on degraded networks.
• Shadowsocks 2022 (SIP022) — The latest Shadowsocks revision adds identity-based authentication, replay protection with bloom filters, and padding. Combined with the "Reduced Redundancy" AEAD variant, it remains a competitive option especially on mobile due to its simplicity and low overhead.
• Trojan + CDN — Trojan running behind a CDN with WebSocket transport provides a simple, effective configuration with strong active probing resistance.

The general trend is toward tools that are indistinguishable from normal HTTPS traffic, have fallback mechanisms for active probing, and can leverage CDN infrastructure to avoid IP blocking. The "look like nothing" approach of early Shadowsocks is giving way to the "look like everything else" approach: instead of trying to be invisible, modern tools try to be identical to the most common traffic on the internet.

The Fundamental Asymmetry

There is a deep asymmetry in the censorship circumvention problem that favors the circumvention side, at least in principle. A censor must decide, in real time, for every connection crossing its border, whether that connection is legitimate or circumvention traffic. The cost of a false positive (blocking legitimate traffic) is high: it disrupts commerce, breaks applications, and generates complaints. The cost of a false negative (allowing circumvention traffic) is lower: one user accesses blocked content.

This means the censor must maintain high precision (few false positives), which limits how aggressively it can filter. Circumvention tools exploit this by making their traffic look as much as possible like legitimate traffic that the censor cannot afford to block.

However, censors have a counterbalancing advantage: they control the network. They can throttle all international traffic, block entire protocols, deploy active probers at scale, and use the legal system to punish users caught using circumvention tools. The arms race continues because neither side has a decisive advantage — it is a ongoing competition between detection precision and evasion sophistication.

Examining Censorship Infrastructure with BGP

Internet censorship systems operate at the network layer, which means their impact is visible in BGP routing data. The god.ad BGP Looking Glass can help you understand the network infrastructure that censorship and circumvention tools rely on.

You can examine the autonomous systems of major censored networks to see how they peer with the global internet:

• AS4134 (ChinaNet / China Telecom) — One of China's largest ISPs, a primary GFW enforcement point
• AS4837 (China Unicom) — China's second-largest ISP backbone
• AS9808 (China Mobile) — China's largest mobile carrier
• AS12389 (Rostelecom) — Russia's state-owned telecom, a primary TSPU deployment
• AS44244 (Iran Cell) — Major Iranian mobile operator

You can also look up the CDN providers commonly used for circumvention relaying — Cloudflare (AS13335), Amazon CloudFront (AS16509), Google Cloud (AS15169) — to see how their IP prefixes are routed globally, including through censored networks. The BGP paths to these CDNs reveal the network hops where censorship enforcement occurs, and the prefix announcements show the scale of infrastructure that would need to be blocked to prevent CDN-based circumvention.

Understanding the routing infrastructure of censored networks is essential for deploying effective circumvention tools: the choice of proxy server location, CDN provider, and transport protocol all depend on how traffic is routed across AS boundaries and where DPI systems are deployed in the path.