Veilora
VLESS Reality SNI: How It Works & How to Choose
The SNI is the single field that decides whether your VLESS Reality tunnel sails past DPI or gets killed on the first packet. Pick it wrong and a technically perfect config still dies.
What the SNI actually is
SNI stands for Server Name Indication. It’s a field in the TLS handshake — sent inside the very first ClientHello, before the encrypted session is fully up — that tells the server which website you’re asking for. One IP address can host thousands of sites, so SNI is how the server knows which certificate to hand back.
Here’s the catch. On a normal HTTPS connection, the SNI travels in the clear. Your ISP can’t read what’s inside your session, but it can read that one name. National firewalls key on exactly this. See a banned name in the SNI → drop the connection. That’s how a lot of “the site just won’t load” blocking works.
For Reality, that same visible field stops being a leak and becomes the disguise.
How Reality borrows a real site’s handshake
Reality flips the usual VPN problem on its head. Instead of generating its own certificate that a DPI box can flag as unknown, it makes your connection wear the TLS identity of a real, major website.
Two settings do the work, and they have to agree:
- The destination (the
dest/targeton the server) — the genuine site your server quietly reverse-proxies TLS to. - The serverName / SNI (what your client presents) — the domain name your client claims to be visiting.
When your client opens a Reality session, it puts that big domain in the SNI. Your server recognizes one of its own clients and steers the session to itself. For anything it doesn’t recognize — an active probe, a curious censor poking the port — it transparently forwards to the real site. So to an outside observer the certificate, the full chain, and the TLS 1.3 fingerprint all belong to that legitimate domain. Nothing self-signed. Nothing novel to catalog.
The SNI you present and the destination you borrow from must be the same real domain. Claim one thing and land somewhere unrelated, and you’ve created a signature instead of hiding one.
Why the SNI choice decides whether you get blocked
The censor’s DPI box asks a blunt question about your handshake: where is this going, and does that look fine? With Reality, the honest-looking answer is a big trusted domain. If that domain is clean and reachable, the traffic passes and you’re through.
If it isn’t, the exact machinery that hides you becomes the thing that flags you. Same tunnel, same crypto, opposite outcome — and the only variable that changed was the name in front. That’s why the SNI isn’t cosmetic. It’s the whole bet.
Worth saying plainly: the strength of your encryption is not what’s on trial here. Reality’s crypto is fine. What DPI judges is the story the handshake tells, and the SNI is the headline of that story. A weak name undoes a strong tunnel every time.
What makes a good SNI (the criteria)
There’s no universal “best SNI for VLESS Reality.” The best one is the domain that passes every check below from the place you actually connect:
- Backed by a large CDN or major provider. Millions of unrelated sites sit behind the same infrastructure, so blocking your destination would mean collateral damage the censor usually won’t accept.
- Reachable from inside the censored country. Test from Iran, Turkey, wherever your users are. A domain that’s fast in Frankfurt but blocked in Tehran is worthless as cover there.
- Not on the local blocklist, clean reputation. Foreign, boring, uncontroversial. No adult, gambling, or already-filtered category.
- Real TLS 1.3 + HTTP/2, so you run allowInsecure=0. The destination must serve a valid certificate over TLS 1.3 with X25519. Then your client verifies the genuine cert and you never touch allowInsecure=1.
- Stable and long-lived. A domain that’s been around for years and won’t vanish or switch CDNs next month.
- Not the tired default everyone copies. SNIs pasted into thousands of public configs are the first ones DPI operators fingerprint.
A fast gate before you commit one → resolve it from the target country, confirm TLS 1.3 in the handshake, and check it isn’t already blocked there. If any of the three fails, move on.
Why a bad SNI gets you blocked
Each criterion maps directly to a failure mode:
- The SNI site is itself blocked in the country. Now your tunnel claims to be visiting a banned destination, so the censor drops it for the same reason it drops the real site. Instant fail — and it looks like your VPN is broken.
- The destination doesn’t really speak TLS 1.3 the way Reality expects. Handshake mismatch. Either it won’t connect at all, or the fingerprint is off enough to stand out.
- allowInsecure=1. You’ve told the client to accept any certificate. Active-probing and MITM boxes love this, because it removes the one check that keeps the disguise honest.
- Overused SNI. Once a destination shows up on scraped public lists, operators can target that exact domain-plus-pattern. Popular is not safe here.
- Destination and SNI don’t match. Claim one domain, land on an IP in an unrelated network, and the inconsistency is a signature all by itself.
Iran is the honest edge case. Even a good SNI can get burned by volume-based, per-IP blocking rather than by the name itself — the disguise holds, but the destination IP draws attention once enough traffic rides a single address. Iran is genuinely hard, and no SNI choice makes it easy. The realistic play there is many low-volume IPs and rotation, not one clever domain.
Veilora picks the SNI for you
If you’re a normal user, none of this is your job. Veilora auto-selects and rotates the SNI and destination per server and per region, tests reachability from the countries that matter, and pushes new values when a candidate starts to degrade — the VeilShift logic behind our VLESS + Reality stack. In our May 2026 survey across 60 ISPs in 4 censored countries, that tunnel restored 92–98% of locally blocked sites — Turkey 92%, Pakistan 98%, India 92%, Indonesia 97% (how we test).
For opsec reasons we don’t publish which production domains we ride. Publishing them is precisely how a good SNI turns into a burned one — the moment a working destination lands on a public list, it’s a target.
If you self-host Xray, the SNI is yours to own and yours to keep testing. Pick a candidate against the criteria above, verify it from inside the target country, and re-check it on a schedule, because a domain that’s clean today can get blocked or move CDNs tomorrow. Our Xray on Android guide shows where these fields live in a real config, and the wider blog covers the rest of the stack.
Your next step
Don’t want to manage any of this? Grab a ready, rotating config from /free-configs/ — 10 GB a month, no card — and let SNI selection happen server-side. If you’re specifically in a hard region, start with the Iran or Turkey guide, or compare your options on our free VPN page. Reality is only ever as good as the name in front of it. Choose that name well, or let something that already does it for you.
Try Veilora free
10 GB every month, free. No credit card required.