VPN vs Shadowsocks vs VLESS+Reality

Who this is for

If you live in Iran, Myanmar, Russia, or mainland China — or you've traveled there and watched your VPN stop working the moment you landed — this post is for you. This is not a guide for the privacy-curious; it is a guide for people who have a specific problem: the network they are on actively blocks circumvention tools, and they need to know what works, what doesn't, and why.

We will walk through three generations of circumvention technology: VPNs, Shadowsocks, and VLESS+Reality. Each was built to solve the failures of the one before it.


Generation 1: VPNs

What they are

A VPN — WireGuard, OpenVPN, IKEv2, or the branded variants built on top of them — creates an encrypted tunnel between your device and a server. Your traffic goes through the tunnel; the destination sees the server's IP, not yours.

Why they get blocked

VPN protocols are distinctive. WireGuard uses UDP on a fixed port with a well-documented handshake. OpenVPN has a recognizable TLS certificate structure. IKEv2 opens predictable port combinations. Deep-packet inspection (DPI) equipment does not need to decrypt your traffic to identify it — it only needs to observe the shape of your packets.

The blocking techniques used by the GFW (China's "Great Firewall") and similar systems in Iran and Myanmar:

Protocol fingerprinting. WireGuard, OpenVPN, and IKEv2 each produce a measurable traffic signature — packet sizes, timing patterns, and handshake sequences that do not appear in ordinary TLS sessions. A classifier trained on these signatures can flag a connection in milliseconds.

Port blocking. Standard VPN ports (UDP 1194 for OpenVPN, UDP 51820 for WireGuard, UDP 500/4500 for IKEv2) are trivially blacklisted at the firewall.

IP reputation lists. The major VPN providers rotate IPs, but their infrastructure is well-known. Residential IP proxies are more resilient, but most consumer VPN apps still rely on datacenter ranges that are monitored.

Active probing. When the firewall suspects a connection might be a proxy, it sends its own crafted packets to the server. A real VPN server responds in a way that confirms it; an ordinary HTTPS server does not.

NordVPN, ExpressVPN, and others now ship obfuscation layers ("obfuscated servers," "NoBorders mode") specifically to fight this. They work in many countries. They fail in the GFW's most aggressive configurations because the obfuscation is a layer on top of a VPN protocol — the underlying shape can still leak.


Generation 2: Shadowsocks

What it is

Shadowsocks was created in 2012 specifically to defeat the GFW. It is not a VPN. It is an encrypted proxy protocol — a SOCKS5-style proxy wrapped in a cipher stream — designed from the beginning to look like random, unremarkable traffic rather than a tunnel.

The core idea: instead of creating a tunnel that announces itself as a tunnel, Shadowsocks sends encrypted bytes that are statistically indistinguishable from a stream of random data. There is no obvious handshake, no certificate exchange, no protocol banner. To passive DPI inspection, the connection looks like noise.

Later improvements added AEAD ciphers (ChaCha20-Poly1305, AES-256-GCM), preventing replay attacks and stream manipulation. Transport plugins like v2ray-plugin wrapped Shadowsocks inside WebSocket-over-TLS, so the traffic looked like HTTPS on port 443 — a major upgrade over raw encrypted streams on random ports.

Where it falls short

Plain Shadowsocks has been partially cracked by GFW active probing since roughly 2019. The attack: the firewall identifies a connection that might be Shadowsocks (the traffic has the right entropy profile, the port is suspicious), then sends its own probe to the server. A standard Shadowsocks server that receives an unexpected probe will either time out or respond with garbage — both behaviors that confirm it is a proxy.

Even with v2ray-plugin and TLS, Shadowsocks has weaknesses:

Certificate problem. When you set the TLS SNI to a domain you don't own (e.g. www.bing.com for camouflage), the server can't present Bing's real certificate. It either uses a self-signed cert — which sophisticated DPI can detect — or requires clients to skip certificate verification, which many clients don't support.

TLS fingerprinting. The TLS handshake generated by v2ray-plugin doesn't perfectly mimic a real browser. The cipher suite ordering, supported extensions, and ALPN negotiation can differ from what Chrome or Firefox would send. Researchers have demonstrated that these fingerprints are detectable.

WebSocket overhead. The WebSocket transport layer adds framing overhead to every packet and an extra round-trip on connection setup.

This is not theoretical. Reports from users in Iran and China since 2022 confirm that Shadowsocks connections — even with v2ray-plugin TLS — are routinely disrupted within hours to days on aggressive networks.


Generation 3: VLESS+Reality

What it is

VLESS is a lightweight proxy protocol from the Xray-core project. On its own, VLESS is just a more efficient transport — the breakthrough is Reality, a TLS implementation that solves the certificate and fingerprinting problems that defeated Shadowsocks.

Reality works by borrowing the TLS handshake from a real website. When a client connects to your server, Reality proxies the TLS negotiation to a legitimate target site (e.g. www.microsoft.com). The client sees Microsoft's real certificate, signed by a real CA, with all the correct TLS parameters. The firewall sees the same thing.

Authentication happens through a separate channel: an x25519 key pair and short ID that the client knows but the firewall doesn't. If a probe connects without the correct credentials, it gets forwarded to the real Microsoft — receiving a genuine Microsoft webpage. There is nothing to expose the proxy.

Why this is different from everything before it

The certificate is real. Not self-signed. Not from Let's Encrypt for your own domain. The actual certificate from the target website, served by the actual TLS stack of that website. DPI that compares certificate chains against known certificates for the SNI domain will find a perfect match.

The TLS fingerprint is real. Reality uses uTLS to generate client hellos that are byte-identical to Chrome, Firefox, or Safari. The cipher suites, extensions, ALPN, and even the padding match what a real browser sends. Fingerprinting tools like JA3 and JA4 see a genuine browser fingerprint.

Active probes see a real website. When the firewall probes the server, it connects without the x25519 credentials. Reality forwards the probe to the real target site. The probe receives a valid TLS handshake, a real HTTP response, and real HTML content. There is no behavior difference between the proxy server and the real Microsoft server — because the response is from the real Microsoft server.

No WebSocket overhead. VLESS+Reality runs directly over TCP with XTLS Vision flow control. No WebSocket framing, no HTTP upgrade, no double encryption. One TLS layer, hardware-accelerated AES-GCM on modern CPUs.

How it works, step by step

  1. Your client initiates a TCP connection to the proxy server on port 443
  2. The TLS ClientHello includes SNI www.microsoft.com and a Chrome-like fingerprint
  3. The proxy server sees the x25519 short ID in the ClientHello and authenticates you
  4. From the firewall's perspective, this looks identical to someone visiting Microsoft
  5. Your VLESS traffic flows inside the authenticated TLS session
  6. If anyone without the correct credentials connects, they get forwarded to the real Microsoft — no proxy behavior exposed

Honest comparison

Standard VPN Shadowsocks + TLS VLESS+Reality (what we run)
Passive DPI Low — distinctive handshake Medium — looks like HTTPS, but cert/fingerprint anomalies High — identical to real HTTPS
Active probing Medium — obfuscated servers help Medium — real TLS, but probe can detect non-browser response High — probe sees a real website
TLS fingerprint N/A — not TLS-based Detectable — v2ray-plugin doesn't match browsers Undetectable — uTLS mimics Chrome exactly
Certificate N/A Self-signed or your own domain Real cert from target site
Speed overhead Low–medium Low (one TLS + WebSocket layer) Lowest (one TLS layer, no WebSocket)
Full tunnel Yes, by default Per-app proxy (TUN mode available) Per-app proxy (TUN mode available)
Client support Native OS Requires SS client with plugin Requires VLESS client (Hiddify, v2RayTun)
Setup One-click QR scan QR scan

What we run

We use Xray-core with VLESS+Reality on port 443.

  • Server: Xray-core with VLESS inbound, Reality TLS, XTLS Vision flow
  • Default target: www.microsoft.com (configurable per user via the dashboard)
  • Authentication: Per-user UUID + x25519 public key + short ID
  • Stats: Per-user traffic accounting via Xray Stats API
  • Access key: A single vless:// URI encodes the full configuration — scan the QR code and connect

Your access key URL looks like:

vless://UUID@server:443?type=tcp&security=reality&sni=www.microsoft.com&fp=chrome&pbk=PUBLIC_KEY&sid=SHORT_ID&flow=xtls-rprx-vision#name

Any client that supports VLESS+Reality will parse this automatically from the QR code.


Trade-offs we accept

It is a proxy, not a VPN. Traffic that does not route through the proxy is not protected or tunneled. Most modern clients handle this with TUN mode, which covers all traffic. Check your client's documentation to confirm TUN support if you need full-device coverage.

It is not an anonymity tool. VLESS+Reality hides your traffic content and makes circumvention resistant to detection and blocking. It does not make you anonymous. The exit server sees your destination. We log bandwidth totals for billing — no timestamps, no destinations, no browsing history. If you need verifiable anonymity, add Tor. VLESS is the tunnel; Tor is the anonymity layer.

You are trusting us with the server. This is true of any proxy service. We are not asking you to take our word for it — we are asking you to evaluate our incentives (we operate a public subscription service with reputational stakes) and make a rational decision.

Reality targets must support TLS 1.3. The target site you impersonate needs to support TLS 1.3 with H2. Most major sites do (Microsoft, Google, Apple, Amazon, iCloud). If a target is blocked or goes down, you can switch targets from the dashboard without changing your access key.


The evolution, in one sentence each

VPNs create a distinctive tunnel that DPI can fingerprint and block.

Shadowsocks removes the fingerprint but is vulnerable to active probing and has certificate/TLS fingerprint weaknesses.

VLESS+Reality makes your connection cryptographically identical to legitimate HTTPS — probes see a real website, DPI sees a real certificate, fingerprinting tools see a real browser.


Get started

Scan the QR code on your dashboard with one of our tested clients:

Plans start at $3/month for 50 GB. If you are connecting from Iran or Myanmar, check our regional pricing — annual Starter is available at a lower price for those regions specifically.

Prefer Telegram? Our support bot handles connection troubleshooting, plan questions, and billing in both English and Farsi.

Crypto accepted: BTC Lightning (phoenixd), USDT-TRC20, and USDC on Base.