A Disguised Packet Still Has to Land Somewhere
Picture the best possible outcome from protocol mimicry. Your handshake is byte-identical to Chrome talking to a normal site. Your session length and packet sizes look like a browser tab someone forgot to close. A censor’s deep packet inspection box looks straight at your traffic and shrugs.
Now picture that flawless disguise pointed at an IP range the state has already decided to null-route wholesale. The packet leaves your machine looking exactly like ordinary HTTPS. It hits a border router that never bothers inspecting it, because the destination address is already on a blackhole list. Perfect mimicry, zero connectivity. The censor didn’t have to notice your traffic at all. They just stopped routing to an entire block of foreign address space and went about their day.
That’s the part protocol mimicry can’t fix, and it’s the actual subject of this article. Once your packets are indistinguishable from normal traffic, the fight stops being about hiding and becomes a fight about geography. You do not win that fight by hiding better. REALITY and its neighbors already did that job about as well as it can be done. You win it by arranging things so that blocking you costs the censor more than tolerating you does.
Collateral Cost as a Design Principle
Every censorship regime, no matter how well funded, runs into the same constraint: it isn’t technical capability, it’s the political and economic cost of collateral damage. A state can absolutely block a specific foreign IP address. It can absolutely block an entire cloud provider’s address ranges. What it usually can’t do without consequence is block a domestic bank’s API, a domestic delivery app’s backend, or the servers hosting half the country’s small businesses, just to catch a fraction of a percent of traffic that happens to be a tunnel.
That asymmetry is the whole game. Every architectural decision from here on should be judged by one question: does this make blocking me more expensive for the people who’d have to approve it? Hiding your traffic well is necessary. It is not sufficient, because a censor doesn’t need to identify your traffic if they’re willing to null-route the entire neighborhood it lives in. The only way to stop that is to make sure your traffic doesn’t live in a neighborhood they can afford to demolish.
The Relay Cascade
The fix for foreign-address blocking is embarrassingly simple to describe and mildly annoying to run: put a relay inside the censor’s own address space between the client and the real exit.
[ Client, on the censored network ] | | looks like ordinary HTTPS to a boring domestic site v[ Domestic Relay, hosted inside the censored country's own IP space ] | | this hop crosses the border, wrapped in REALITY / XHTTP v[ Foreign Exit Node ] | v[ The rest of the internet ]The client’s packets never target a foreign address. They target a server sitting on domestic infrastructure, using a domestic IP, on a domestic ASN. Whatever the censor is doing to foreign address space, blanket null-routing, ASN-level blackholing, aggressive rate limiting on known VPN and cloud ranges, has nothing to grab onto here. The only hop that crosses the border is between two servers, not between the client and the outside world, and that hop is already wearing the REALITY disguise from the second article in this series.
This is why a domestic entry point beats simply renting a nicer foreign exit. A better foreign VPS gives you a faster, cleaner tunnel that is still, from the censor’s point of view, a foreign address they can null-route on a Tuesday afternoon with a single firewall rule. A domestic relay removes that button entirely.
None of this is free. An operator running a setup like this reports a fairly modest hardware baseline for the relay, roughly 2 vCPUs and 2 GB of RAM, and a round trip cost from the extra hop of around 120 milliseconds. That’s the operator’s reported number for their setup, not a benchmark you should expect to reproduce exactly, and it lines up with what you’d expect from bouncing a packet through an extra hop and back out. It’s fine for browsing, fine for voice calls, and noticeably bad for anything twitchy like competitive gaming. If your use case is “get online and stay online,” that’s a trade worth making every time.
What the Domestic Relay Actually Buys You
This is the part worth being precise about, because the field reports behind this setup tend to oversell it, and the oversold version is exactly what gets people hurt when they rely on it for the wrong thing.
The part that’s real and reliable
A domestic relay defeats blanket foreign-IP and foreign-ASN blocking. That’s the everyday, load-bearing benefit, and it genuinely works. Your traffic never asks the censor’s border equipment to make a decision about a foreign destination, because there isn’t one in the path the censor can see. This is the mechanism that keeps a setup like this online through the routine, low-grade blocking that most censored networks run day to day.
The part that’s oversold
What a domestic relay does not do is put you on a shutdown whitelist. This distinction gets flattened in a lot of field write-ups, and it matters enough to spell out with actual public reporting rather than vibes.
Russia’s Ministry of Digital Development publicly announced service whitelists in August 2025, starting with 57 sites that September and expanding repeatedly since. It was around 120 platforms in March 2026 and passed 500 by that May: mobile operators, federal media outlets, government agency portals, major online marketplaces, domestic social networks, the state messenger, banks, food delivery apps, and the big taxi services. These aren’t categories, they’re specific named services, each one registered and hosted on domestic infrastructure.
Nobody has published the admission criteria as a formal rule, so treat what follows as a reading of the evidence rather than a quoted policy. The pattern in the reporting is that a slot on the list tracks how compellable an operator is: Human Rights Watch noted that banks which failed to comply with security service demands were dropped from the whitelist. A list that behaves that way has no slot for a general-purpose VDS that happens to sit in the same address space, no matter how domestic that address space is. Renting a box in the right country does not make you the kind of entity that gets listed.
It gets worse under real stress, too. During a roughly three-week shutdown in Moscow in March 2026, even the whitelisted services degraded badly. Human Rights Watch, the OSW Centre for Eastern Studies, and The Record all reported on it. The clearest documented cause is dependency failure: HRW spelled out that whitelisted services still broke because they rely on external resources like mapping tools and analytics systems that nobody put on the list. Being permitted is not the same as being functional when half of what your app calls out to is still blocked.
None of this means the relay cascade is a bad idea. It means the honest explanation for why it works is narrower than the popular one. It stops routine foreign-IP blocking cold. It was never designed to, and can’t, survive a whitelist-only shutdown. Treat it as a very good answer to the problem it actually solves, not as a hedge against the problem it doesn’t.
Redundancy Done Right
Spreading relays across more than one domestic provider is the correct instinct. Putting all your eggs in one domestic VDS account means one account suspension away from silence, and providers in these markets do get pressured. Multi-provider redundancy is worth the extra admin overhead.
Where the usual advice goes wrong is the failover mechanism. Low-TTL DNS looks like the obvious answer: point a name at relay A, drop the TTL, swing it to relay B if A dies. It falls apart because DNS itself is one of the most reliably poisoned and hijacked layers in a censored network. You’re proposing to route your failover decision through the exact system that’s already lying to you.
The better pattern is a client-side multi-endpoint list: bake a handful of relay addresses directly into the client config, have the client health-probe each one on its own schedule, and let it fail over automatically without ever asking a DNS resolver it can’t trust. It’s a little more setup work up front and it doesn’t depend on a layer that’s actively working against you.
When picking a domestic relay host, without naming anyone, look for a few boring but decisive things: a provider large and established enough that it isn’t a single administrative decision away from folding, billing that doesn’t require identity verification tied directly back to you, an acceptable-use policy that doesn’t explicitly ban proxy or VPN traffic, and enough scale that your account doesn’t stand out as a tiny anomaly in their customer base. None of that is exotic. It’s the same due diligence you’d apply to any vendor you don’t want going away at the worst possible moment.
CDN Transit, With a Domain You Own
The transport that makes the relay cascade practical is XHTTP, formerly called SplitHTTP. It wraps proxy traffic inside HTTP requests and works over HTTP/1.1, HTTP/2, and HTTP/3, with modes like packet-up and the upload-optimized stream-up mode. The useful trick is splitting upload and download traffic across separate connections, which defeats simple pattern analysis and makes TLS-in-TLS detection meaningfully harder to pull off reliably. In a typical deployment the client speaks HTTP/3 to a CDN edge, and the CDN speaks HTTP/2 or HTTP/1.1 back to your actual Xray server. It is a real stream transport built for exactly this, not header stuffing dressed up as something clever.
That CDN layer is where a common misconception needs correcting: this is not domain fronting. Classic domain fronting relied on a mismatched TLS SNI and HTTP Host header both served by the same CDN, letting you claim to be talking to one domain while actually reaching another. That trick is dead everywhere you’d actually want to use it. Cloudflare returns a 421 on SNI and Host mismatches, and Amazon, Microsoft, and Google all closed the loophole back in 2018 and prohibit the technique in their terms. MITRE ATT&CK tracks it as T1090.004 with a documented detection strategy built around logging exactly that kind of mismatch. Some smaller regional CDNs never bothered to close it, and variants like blank-SNI “domainless” fronting still turn up against misconfigured infrastructure, so it isn’t extinct in the strictest sense. But it’s a detected technique on every provider with the scale to give you meaningful collateral protection, which makes it useless for this purpose. Building a plan around it in 2026 is building on sand.
What actually works is CDN transit using a domain you legitimately own, running VLESS over XHTTP or WebSocket behind that CDN. You get the same collateral-damage protection domain fronting used to promise, because a censor blocking your CDN edge blocks everyone else riding that CDN too, but you get it through a legitimate mechanism instead of a header trick that every major provider now actively hunts for.
Ephemeral by Design
The single best idea in the field reports behind this cluster has nothing to do with cryptography. It’s the operational mindset: treat every node as disposable. Relays and exits in a network like this get burned every few months, whether from a specific block, an account suspension, or just drift. The correct response isn’t to fight for uptime on a node that’s already living on borrowed time. It’s to make rebuilding trivial.
That means infrastructure as code from day one: Terraform for provisioning, Ansible for configuration, templates sitting in a private repo so a new node comes up in the same state every time. It means baseline kernel tuning as part of that template, BBR congestion control and the relevant sysctl values, applied automatically rather than remembered by hand at 2 AM. It means monitoring that’s deliberately lightweight, a script that alerts on link failure rather than a dashboard nobody watches.
# the rough shape of a rebuild loop, not a literal scriptterraform apply -var="target=new-domestic-relay"ansible-playbook -i inventory/new-node.ini site.yml# push the fresh config bundle behind the CDN-fronted subscription URL# retire the old node, update the client-side endpoint list# clients pick up the new relay on their next health probe, no DNS involvedThe mindset generalizes well past censorship circumvention. Any infrastructure you expect to get taken away from you, by a provider, a regulator, or plain bad luck, benefits from being optimized for rebuild speed instead of uptime. That’s the actual innovation here, and it’s worth stealing for reasons that have nothing to do with any of this.
The Bootstrap Problem
Here’s the part the field reports skip entirely, and it’s the part that actually breaks setups in practice: ephemeral infrastructure means you’re constantly redistributing fresh configs and keys to real people, and the channel you use to do that is itself sitting inside a censored network.
There’s no clean answer to this, and pretending otherwise does readers a disservice. What works, imperfectly, is layering several channels so no single failure cuts everyone off at once: out-of-band delivery through channels the censor isn’t actively watching that week, a pre-shared list of fallback endpoints baked directly into the client so a first connection doesn’t depend on fetching anything at all, subscription URLs served from behind the same CDN layer your traffic already rides, and, for people you can actually reach in person, a QR code handed over directly. Every one of those has a failure mode. Stacking them means you’re rarely down to zero at once, but you are never down to a guaranteed one either.
Where This All Runs Out
When a network moves from routine blocking to a whitelist-only shutdown, none of this saves you. Not the relay cascade, not the CDN transit, not the disposable infrastructure. A whitelist-only network isn’t blocking specific things anymore, it’s permitting a short, named list and dropping everything else, and no amount of clever routing gets you added to a list that’s gated on legal compliance obligations you can’t take on as an individual. This is the point where the relevant answer stops being a tunnel at all and starts being offline-first tooling and long-range radio mesh networking, tools built to work without an internet connection in the loop rather than tools built to sneak one past a filter.
One last thing worth saying plainly and without turning it into a lecture: rules around VPN use and circumvention tooling vary a lot by jurisdiction and have been getting stricter in places, so it’s worth knowing where you actually stand before you build any of this.
