China: how the Great Firewall treats proxy traffic

What peer-reviewed research shows about how the Great Firewall detects proxies and encrypted traffic, and which 2026 claims cannot be verified.

Last reviewed:

China's Great Firewall is the best-studied censorship system, and that helps: some of what it does is documented in peer-reviewed papers, not only in forum posts. This article separates those findings from the many unverified claims, and says what they imply for the choice of protocol.

What the research shows

  • Active probing of Shadowsocks. According to the authors of the 2023 paper below, China had been using passive traffic analysis and active probing against Shadowsocks since May 2019. The IMC 2020 study describes how the system sends its own probes to a suspected server and blocks it if it answers like a Shadowsocks server.
  • Blocking of fully encrypted traffic. In November 2021 the firewall began blocking connections whose first packet looks like fully encrypted data, in real time and without probing. Wu et al. (USENIX Security 2023) show that the detector does not try to identify a protocol. It first exempts first packets that do not look like random data, for example those that start with a recognisable protocol header or consist mostly of printable characters, and blocks what remains.
  • TLS inside TLS. Xue et al. (USENIX Security 2024) showed that a TLS handshake carried inside an obfuscated connection betrays a proxy, even with random padding. They built a classifier and tested it at a mid-sized ISP. That is a demonstration of what is detectable. How widely any censor uses it is a separate question that public measurements do not settle.

What that means for protocol choice

SetupFirst packet looks likeExposure to the 2021 detector
Shadowsocks without a plug-inRandom bytesIn the targeted group
VMess over plain TCPRandom bytesIn the targeted group
Trojan, or VLESS or VMess over TLSA TLS handshakeNot in that group; still exposed to checks on address, server name and certificate
VLESS with REALITYA TLS handshake to a real siteNot in that group; address and TLS-in-TLS patterns still matter

The practical rule that follows from the papers: avoid setups whose first packet is random-looking, and prefer ones that start with a real TLS handshake. The protocol guide explains the options.

What you cannot rely on

You will find posts that give exact detection rates for REALITY or for a specific cipher in 2026, or that describe a dated escalation. We could not verify any of them against independent measurement, and most come from companies that sell VPN services. The firewall changes, and the safe assumption is that any single setup can stop working.

Habits that help

  • Keep spares from different hosts and refresh your subscription. Blocking by address is routine.
  • Do not publish configs. A shared address is blocked sooner.
  • Behind a CDN (VLESS or Trojan over TLS and WebSocket) the server's own address is hidden, but the CDN's addresses can be throttled. Reports of this vary and we have not measured it.
  • Test on each network you use. Fixed and mobile networks can behave differently.
  • Read the claims critically. "Undetectable" is not a property any protocol has. It is a statement about a particular firewall at a particular time.

Sources

Bring your configs. Leave the guesswork.

Free on the App Store for iPhone, iPad and Mac.