Building Self-Hosted Tunnels Under Extreme Censorship: A Layered Architecture with VLESS Reality

Before discussing any technical solution, you must first define the threat model—because it determines the entire architecture's design logic. A self-hosted tunnel operator based in Russia shared real-world operational experience on Reddit. Its value lies not in introducing a specific tool, but in revealing a harsh reality: the vast majority of advice about self-hosted tunnels assumes a neutral network, and none of that advice survives in a truly adversarial network environment.

This contributor previously worked at a local ISP, so he knows exactly what "the other side of the firewall" can see. This makes his analysis exceptionally valuable.

Threat Model: When Your Adversary IS the ISP

In most people's understanding, the adversary when bypassing censorship might be random port scanners or a firewall that can block IPs. But in this author's scenario, the adversary's capabilities are far more formidable:

The adversary is the ISP itself, operating under a regulatory framework that enforces nationwide DPI (Deep Packet Inspection);
Network operators can null-route entire foreign IP ranges based on geographic location;
Operators have complete visibility into traffic shapes and can actively probe any endpoint you set up.

DPI: It's Not Just About Content—It's About Silhouettes

DPI is a network traffic analysis technology. Unlike traditional packet filtering (which only examines IP headers and port numbers), DPI can inspect the complete payload of data packets. Modern DPI equipment is typically deployed at ISP core routing nodes, capable of analyzing tens of Gbps of traffic in real time. Its identification methods include: signature matching (identifying fixed byte patterns of known protocols), statistical fingerprinting (analyzing packet size distributions, timing intervals, burst patterns, etc.), and behavioral heuristics (detecting whether connection establishment patterns match a protocol's typical behavior). Since 2017, Russia has deployed standardized DPI hardware across all national ISP nodes through the TSPU (Technical Counter-Threat Equipment) system, centrally managed by the communications regulator Roskomnadzor, transforming traffic inspection from an optional ISP behavior into part of mandatory national infrastructure.

In other words, the adversary doesn't need to decrypt your traffic—it only needs to identify the traffic's "silhouette", or simply block entire foreign IP ranges based on geography. These two capabilities alone are a death sentence for conventional solutions.

Null-Route: The Most Brutal Yet Effective Block

Null-routing is one of the most brutal but effective blocking methods available to network operators. It works by pointing the next hop for target IP ranges in the routing table to a "black hole" interface (typically Null0), causing the router to silently drop all packets destined for those addresses without generating any ICMP error replies. Unlike firewall rules, null-routes consume virtually no device resources, take effect in milliseconds, and can be applied to entire /16 or even /8 address blocks simultaneously. Russia's TSPU system can push null-route directives to border routers at every ISP nationwide, enabling bulk blocking of IP ranges belonging to specific countries or regions. This means that even if your VPS perfectly disguises its traffic characteristics, if its IP address belongs to a flagged foreign ASN (Autonomous System Number), packets will simply be dropped.

Why Conventional VPN Solutions Are Completely Defeated

The author makes a razor-sharp observation: OpenVPN and WireGuard are both out of the game in this environment.

They aren't blocked by IP—they're identified by shape. WireGuard's handshake has a fixed message layout and distinctive packet size distribution. DPI doesn't need to decrypt anything—it just needs to recognize this "silhouette." OpenVPN's opcode structure is equally identifiable.

Specifically, WireGuard is easy for DPI to identify due to its minimalist protocol design philosophy. WireGuard defines only four message types (Handshake Initiation, Handshake Response, Cookie Reply, Transport Data), each with fixed 4-byte type identifiers and fixed message lengths. For example, the handshake initiation message is always 148 bytes, and the handshake response is always 92 bytes. These highly consistent characteristics allow DPI devices to determine with extremely high confidence that traffic is WireGuard by examining just the first few bytes and packet length of a UDP datagram. OpenVPN is similar—its TLS control channel uses opcodes at fixed positions in each packet header, and even with the tls-crypt option enabled, the initial handshake's packet structure still has identifiable statistical characteristics.

As for various obfuscation wrappers? The author's assessment is: "They buy you weeks, not months."

The takeaway is clear. When the adversary has DPI capabilities, the protocol's inherent characteristics become the biggest vulnerability—no matter how strong the encryption, if it "looks like a VPN," that's enough to be flagged and blocked.

First Layer of Defense: VLESS + Reality Disguise Mechanism Explained

The first layer of the author's current architecture is VLESS + Reality based on Xray-core. Reality's working principle deserves deep understanding:

Core Mechanism of the Reality Protocol

The client initiates a standard TLS handshake, but sets the SNI to a real major website (the author uses www.microsoft.com);
Authentication materials (an X25519 public key plus a short ID) are hidden within the ClientHello. To DPI, this appears as just an ordinary string of bytes in the service fields;
The server validates these materials: if valid, it completes the handshake itself and proxies traffic; if invalid or missing, it silently forwards the entire connection to the real Microsoft server;
Therefore, when the adversary conducts active probing, they receive genuine Microsoft responses—real certificates, real certificate chains, real content. The machine looks like a mirror of Microsoft with no anomalous fingerprints;
No need for your own TLS certificate (nothing to leak) and no need for your own domain (nothing to be blacklisted in registries).

SNI and TLS ClientHello: Why Reality Can Hide in Plain Sight

The first message in a TLS handshake is the ClientHello, which is sent in plaintext (since encryption hasn't been established yet). The ClientHello contains multiple extension fields, the most critical being SNI (Server Name Indication), which tells the server which domain the client wants to access so the server can return the correct certificate. This design was originally intended to support multiple HTTPS websites hosted on a single IP, but it also became a powerful tool for DPI censorship—censors can read the plaintext SNI field to know what website a user is visiting without decrypting any traffic. Although ECH (Encrypted Client Hello) technology attempts to encrypt this field, as of 2025, ECH deployment remains limited, and its use itself may become a flagged characteristic. The Reality protocol cleverly leverages the SNI mechanism by setting it to genuine major website domains, making the traffic completely legitimate at the SNI level.

X25519 Key Exchange: Authentication Steganographically Embedded in Legitimate Protocol Structures

X25519 is a Diffie-Hellman key exchange algorithm based on the Curve25519 elliptic curve, designed by cryptographer Daniel J. Bernstein. Its core advantages are: keys are only 32 bytes long, computation is extremely fast, and it has excellent resistance to side-channel attacks. In the Reality protocol, the X25519 public key is embedded in specific fields of the TLS ClientHello (typically session_ticket or other variable-length extension fields), combined with a short ID (usually an 8-byte hexadecimal string) to form authentication credentials. Since the TLS specification allows these fields to contain arbitrary binary data, DPI devices cannot distinguish them from a normal TLS handshake. This design achieves a "steganographic" effect—authentication information is hidden within the protocol's legitimate structures rather than transmitted through an additional channel.

Key Significance for Self-Hosters

The most critical change Reality brings is: your endpoint can no longer be distinguished through content inspection. When the "inspect content" path is blocked, the adversary can only turn to the next attack surface—the geographic layer.

Second Layer of Defense: Domestic Relay to Solve Geographic Blocking

The author emphasizes a key fact that's easily overlooked: Reality solves the "detection" problem, not the "geography" problem.

A VPS located in the Netherlands is easily blocked—the adversary doesn't need to know what it's doing, only that it's abroad.

Using Whitelisted Domestic IPs as Relay Fronts for Foreign Endpoints

His solution is ingenious: the client never directly contacts the foreign machine.

The entry point is a relay server deployed at a Russian local provider whose IP range falls within the "national whitelist"—these IP ranges remain reachable even during regional mobile internet shutdowns because government and banking services run on them;
Traffic cascades from the relay to the foreign machine in the Netherlands;
From the outside, this connection appears to be a request to "approved domestic infrastructure."

Collateral Damage Is the Real Defense Barrier

Hidden here is the most elegant design principle of the entire architecture: to block this IP range, they'd have to take down a large number of legitimate commercial services sharing the same address space.

The author's exact words: "Collateral cost is the real defense mechanism—not stealth."

This is a classic "hostage strategy": hiding yourself behind critical infrastructure that the adversary cannot afford to accidentally damage. This strategy isn't the author's invention—academia refers to it as a broad variant of "domain fronting." In 2018, when Russia attempted to block Telegram, it added large swaths of Google and Amazon IP ranges to its blacklist, resulting in thousands of unrelated services going down, ultimately forcing them to rescind the blocking order. This incident proved the effectiveness of the collateral damage strategy: when the side effects of blocking are severe enough to affect economic operations and the government's own services, the blocking itself becomes unsustainable. Compared to pursuing technically perfect invisibility, exploiting the adversary's fear of collateral damage is more reliable and more durable.

Operational Strategy: Designed for Rapid Rebuilding

The author's description of operational realities is highly pragmatic:

Gets blocked every few months, then rebuilds. Planning focuses on "rebuild speed" rather than "permanence";
Tech stack: Xray-core 26.3 running on Ubuntu 24, VPS configured with 2GB RAM, 2 cores. Reality has very low resource requirements; the machine sits idle most of the time;
Latency cost: Cascade forwarding adds approximately 120ms. Daily browsing and voice calls work perfectly fine, but latency-sensitive scenarios like gaming are noticeably affected—this is the necessary price for avoiding geographic blocking;
Monitoring: Custom scripts check tunnel status across all servers and send email notifications. The approach is rough but ensures alerts arrive before users perceive failures;
Fallback path: Currently migrating the fallback to XHTTP over CDN, stuffing upstream data into HTTP headers to make traffic look like ordinary web requests.

XHTTP over CDN: Design Logic for the Backup Link

XHTTP is a newer transport protocol in the Xray-core project, specifically designed for relaying traffic through CDNs (Content Delivery Networks). Its core approach is to split and encapsulate proxy data into standard HTTP requests and responses: upstream data is transmitted via HTTP POST request bodies or custom headers, while downstream data is streamed back via chunked transfer encoding in HTTP responses. Since traffic passes through major CDN providers like Cloudflare or Fastly, the censor sees destination IPs belonging to CDN edge nodes—addresses that simultaneously serve millions of legitimate websites. Blocking CDN IPs means simultaneously crippling vast amounts of normal internet services, which is another application of the "collateral damage" strategy at the transport layer. However, CDN relay introduces additional latency and potential speed limitations, so it's typically used as a fallback when the primary link fails.

Single Point of Failure: The Unsolved Challenge of Relay Redundancy

At the end of his writeup, the author raises an open question that's also the architecture's biggest weakness:

Is anyone else using the "domestic relay fronting a foreign endpoint" approach rather than trying to obfuscate the endpoint itself? I'm particularly interested in relay failover—currently my relay is a single point of failure, and I'm not happy about it.

This is indeed the Achilles' heel of this architecture. The entire scheme's security rests on that "domestic relay within the whitelist." If it goes down, no matter how well-hidden the foreign endpoint is, it's useless. But adding redundancy to the relay means needing more resources within whitelisted IP ranges, significantly increasing cost and complexity. Theoretical solutions include: deploying relays at multiple different providers with automatic client-side failover, using Anycast addresses for seamless failover, or leveraging Serverless platforms (like Cloudflare Workers) as dynamic entry points. But each approach has its own limitations—multiple providers increase the exposure surface, Anycast requires your own ASN and IP ranges, and the availability of Serverless platforms themselves may be affected by censorship.

Layered Adversarial Thinking: Lessons for Tunnel Design in Extreme Environments

The greatest value of this writeup is that it demonstrates layered adversarial thinking for tunnel design in extremely hostile environments:

Content layer: VLESS + Reality solves the "being identified" problem, making endpoints indistinguishable via DPI;
Geographic layer: Domestic whitelisted relays solve the "geographic blocking" problem, hiding within infrastructure the adversary dares not damage;
Operational layer: Abandoning the illusion of permanence in favor of rapid rebuilding and proactive monitoring.

This layered thinking aligns with the "Defense in Depth" principle in information security, but in the completely opposite direction—traditional defense in depth is where defenders build successive barriers to prevent attackers from penetrating deeper, while here the breakthrough party uses successive layers of disguise to penetrate the blocker's defenses. No single layer pursues perfection; instead, each addresses threats in a specific dimension, and their combination creates overall survivability.

For anyone doing technical work in restricted network environments, the core insight of this approach is: when the adversary is powerful enough, pure technical stealth is insufficient—you need to exploit the adversary's own constraints. Making the cost of blocking you too high for the adversary to bear is often more realistic and more durable than trying to be completely invisible.