REALITY disguises itself during the TLS handshake and certificate delivery, returning certificates and initial data that appear to be from a legitimate website during the handshake, making the TLS connection and access to "major" HTTPS websites difficult to distinguish. The GFW risks accidentally blocking legitimate websites if it wants to block them.
The honest answer: they sometimes do, increasingly so, and that's why this is an active arms race rather than a settled problem.
Below is why an SNI↔IP correlation check is harder than it looks, why Russian TSPU and the GFW don't apply it universally, and how REALITY's design tries to defeat it anyway.
If a censor wants to verify "client claims SNI = www.microsoft.com, does the destination IP actually belong to Microsoft?", they immediately hit problems:
- CDNs / shared hosting: A massive fraction of "popular" sites resolve to Cloudflare, Akamai, Fastly, AWS CloudFront, Google Cloud, etc. One IP serves thousands of unrelated domains via SNI. So "this IP doesn't belong to Microsoft" isn't dispositive — many real Microsoft properties live on Akamai/Azure Front Door IPs, and many non-Microsoft sites live on Microsoft IPs.
- Anycast + geo-DNS: The same domain returns wildly different IPs per region, per resolver, per time. The censor's resolver view ≠ the client's view.
- Multiple A/AAAA records: Big sites publish dozens of IPs that rotate frequently. The censor would need a constantly-refreshed, region-specific map of every popular domain → every legitimate IP, at line speed.
If the client uses DoH / DoT / DNSCrypt, the censor never sees what IP the client thinks corresponds to the SNI. Without that, "mismatch" detection has no baseline — the censor only sees the TLS connection itself.
Russia's TSPU does heavily fingerprint and throttle DoH endpoints, but it can't observe the resolution itself once it's encrypted.
TSPU sits on operator backbones inspecting tens to hundreds of Gbps. Per-connection real-time DNS validation against an authoritative cache is expensive, and any false positive blocks real users from real services — politically and economically painful. So in practice the check is applied selectively (suspicious ASNs, suspicious traffic patterns) rather than to every TLS connection.
What Russian DPI (and the GFW) is observed doing instead:
- ASN / hosting-provider reputation: Flag connections to ASNs known for VPS hosting (Hetzner, DigitalOcean, OVH, Vultr, etc.) more aggressively than connections to known consumer-CDN ASNs.
- Statistical traffic profiling: Long-lived high-volume TLS sessions to small ASNs get scored higher.
- Active probing: Open a TLS connection to the suspicious IP themselves and see whether it behaves like the claimed SNI.
- Residual censorship: After detection, blackhole the IP for some period.
These are weaker than per-connection SNI/IP matching but cheaper and politically safer.
Re-read the REALITY README criteria with this in mind:
"Bonus points: target website IP reside closer to proxy IP (looks more reasonable, and lower latency)"
That bullet is precisely about defeating SNI/IP correlation. The recommendation is:
- Pick a
destwhose IP is in an ASN / region / hosting provider plausibly close to your VPS. - Ideally the
destis itself hosted on a major cloud (Azure / AWS / GCP / Cloudflare), so the IP block is "mixed-use" and a censor can't say "this IP isn't Microsoft" — it might be Azure, where Microsoft and a million other things live. - Use
RealiTLScannerto find domains that are actually hosted in your VPS's neighborhood and meet the TLS criteria.
If you put a German VPS behind SNI www.apple.com, an SNI/IP check is trivially fatal: Apple's IPs aren't in Hetzner. If you put it behind some Microsoft-cloud-hosted SaaS in the same European Azure region, the picture is much muddier.
Public reports (Roskomsvoboda, GlobalCheck, ntc.party threads) suggest TSPU's REALITY-targeted detection has leaned more on:
- whitelist-based protocol allow-listing on certain segments,
- statistical/behavioral analysis of long sessions,
- ASN-based scrutiny,
…rather than wholesale per-connection SNI/IP validation. But the trajectory is clearly toward more correlation, and operators have observed targeted blocks of REALITY setups whose dest choice was implausibly distant from the server IP.
It's not that Russian DPI can't check SNI vs. IP — it's that doing it accurately at scale is expensive, encrypted DNS denies it the baseline, CDNs make "mismatch" ambiguous, and false positives are politically costly. So they do it coarsely (ASN/behavior heuristics + active probing) rather than precisely. REALITY's "pick a dest whose IP is close to yours" recommendation exists specifically because the coarse version of this check is real and getting better.