How DPI Detects Proxies and How to Defeat It on a VPS

The single cheapest thing a DPI box can do is read the Server Name Indication (SNI) field inside the TLS ClientHello. Even though the rest of a TLS 1.2/1.3 session is encrypted, the SNI - the hostname the client wants to reach - is sent in cleartext during the handshake by default. Censors keyword-match it against a blocklist and drop or reset the connection before a single byte of your tunnel flows. This is how most national firewalls block known VPN domains, Tor's default bridges, and any proxy whose endpoint resolves to a flagged hostname. It is passive, stateless, and runs at line rate, so it is the first filter your traffic meets.

There are two real countermeasures, and they work at different layers. The first is encrypting the SNI itself via Encrypted Client Hello (ECH), the successor to ESNI. ECH wraps the inner ClientHello (including SNI) inside an outer one addressed to a public-facing name, so the DPI sees only the cover name. The catch: ECH needs both client and the fronting infrastructure to support it, and some censors have responded by simply blocking ECH ClientHellos wholesale, which makes ECH itself a fingerprint in the most aggressive networks.

The second, and currently more robust, countermeasure is to not present a censorable SNI at all - which is exactly what the Reality transport (VLESS+Reality in Xray or sing-box) does. Your client sends the SNI of a real, allow-listed website; your server, for any handshake it cannot cryptographically authenticate, transparently relays to that real site and returns its genuine certificate. The censor reads an SNI it has no reason to block and, if it probes, gets a legitimate site back. We cover Reality's domain-free setup in detail in our offshore VPS guides; the key point here is that it neutralises SNI inspection by borrowing a name the censor already trusts.

Passive inspection alone produces false positives, so sophisticated censors add active probing. When a flow looks suspicious but is not conclusively a known protocol, the firewall records your server's IP and port and, seconds to hours later, opens its own connection to that endpoint and speaks the suspected protocol. If your server responds the way a Shadowsocks, obfs4, or VMess server would - or even just behaves abnormally for whatever it is pretending to be - the endpoint is flagged and blocked. This is precisely how the Great Firewall historically discovered Tor bridges and naive Shadowsocks servers: it replayed handshakes and watched the reaction.

The defeat is to make your server indistinguishable from a benign service to anyone who lacks the key. Modern transports build this in:

• Reality / TLS fallback: an unauthenticated prober is forwarded to the real borrowed website and sees that site's normal response. There is no proxy behavior to detect because the prober never reaches the proxy.
• obfs4: uses a per-bridge secret in the handshake, so a prober that does not already possess the bridge's key cannot even complete the handshake and gets nothing distinguishable to fingerprint.
• AEAD Shadowsocks (2022 edition): replaced the older stream ciphers that let probers detect a wrong-password response, closing the replay/probe oracle that earlier versions exposed.

The operational rule that ties these together: run nothing else probable on the same IP and port. If a prober hits your port 443 and finds a self-signed admin panel, an open SSH banner on a guessable port, or a redirect, the anomaly your transport tried to hide is handed right back. Keep management on a firewalled, non-standard port, default-deny inbound, and let the only externally visible thing be a clean, real-looking handshake. Full root control on a self-hosted VPS is what makes this lockdown possible.

When SNI is hidden and probing is resisted, advanced DPI falls back to statistical traffic analysis - judging a flow by its shape rather than its content. Three signals dominate.

Byte entropy. Fully encrypted proxy protocols (early Shadowsocks, VMess without TLS) produce a stream that is high-entropy from the very first packet, with no plaintext handshake. Real protocols rarely look like that: even TLS begins with a structured, low-entropy ClientHello. In 2021-2022 the Great Firewall deployed an entropy-and-popcount classifier that blocked flows whose first packet was "too random" - it specifically targeted protocols that try to look like nothing at all. The lesson is counterintuitive: looking like random noise is itself a fingerprint.

Packet size and direction patterns. A tunnel that wraps TLS inside TLS (a proxy speaking TLS to its client, carrying the client's own TLS to a website) produces a recognisable record-size and read/write pattern - the "TLS-in-TLS" signature. Researchers have shown this is detectable with high accuracy because the inner handshake's bursts leak through the outer one.

Timing and volume. Persistent, high-throughput, long-lived flows to a single foreign IP that carry interactive and bulk traffic at once look unlike normal browsing and can be scored as a tunnel.

The countermeasures map directly onto each signal. Against entropy classification, imitate a real protocol instead of hiding: Reality and VLESS+TLS present a genuine TLS 1.3 handshake, so the first packet has exactly the structure DPI expects. Against the TLS-in-TLS pattern, use the XTLS Vision flow, which reshapes the inner session so its packet sizes stop leaking the nested handshake. Against timing analysis, modern transports such as Hysteria2 and TUIC run over QUIC/UDP with built-in padding and congestion control that blend with ordinary HTTP/3 video traffic, and you can split bulk and interactive use across separate flows. None of these require obscure tooling - they are configuration choices in sing-box or Xray on a standard VPS.

The most aggressive censorship posture abandons blocklists entirely and switches to protocol allow-listing: instead of blocking what looks bad, the firewall permits only what looks unambiguously like a sanctioned protocol - typically HTTPS (TLS over 443), DNS, and HTTP - and throttles or drops everything else. This has been observed during high-control events and in the most restrictive networks. Allow-listing is brutal for anything novel, because a brand-new obfuscation that does not resemble permitted traffic is dropped not for being detected but for not being on the list.

The only durable answer to allow-listing is to actually be the permitted protocol, convincingly. That means:

• Live on 443 and speak real TLS 1.3. Reality and VLESS+TLS produce handshakes that are not merely similar to HTTPS - they are HTTPS, terminating in a real certificate. To the allow-list they are exactly the traffic class that is allowed.
• Use HTTP/3 camouflage where UDP is permitted. Hysteria2 and TUIC ride QUIC, the transport of HTTP/3, so on networks that allow QUIC video traffic they pass as the dominant modern web protocol rather than as an exotic tunnel.
• Avoid bespoke ports and bespoke framing. Anything on an unusual port or with a custom header is the first casualty of an allow-list. The closer your endpoint sits to genuine web traffic, the harder it is to exclude without collateral damage the censor cannot afford.

This is also where your hosting choice becomes a countermeasure rather than an afterthought. A clean, dedicated IP that has never been associated with a flagged service starts with no reputation penalty; a shared or recycled IP may already sit on a blocklist before you configure anything. Full root access lets you bind to 443, control the certificate, lock down every other port, and rotate the endpoint if an IP degrades. For a single private endpoint an offshore VPS is the right fit; for higher throughput or many users where you want guaranteed headroom and a fully isolated IP, an offshore dedicated server removes the shared-IP risk entirely. The protocol defeats the DPI; the clean offshore IP and root control are what keep that protocol viable over time.