v5 vs v6 against the GFW

The honest short answer:

This page assumes the threat model from Comparison with Other Protocols — the passive censor (offline classifiers) and the active censor (probes and replays flagged endpoints). The GFW blocks a proxy through roughly four capabilities; v6 changes one of them substantially and leaves the rest where v5 was.

1. Protocol-class fingerprinting — where v6 wins

This is the one that matters, and it's the whole reason v6 exists.

v5 has a single, deployment-independent wire shape. Every v5 server lays the 16-byte salt down contiguously, sizes its frame header the same way, and shapes its padding by the same rule. The high-entropy paradox section makes the key point: v5's padding shaping makes it look less like random ciphertext to a blunt entropy classifier — but that shaping is itself a fingerprint. Once a researcher publishes "a frame whose salt + padding + payload lands at this bit ratio, with a consistent padLen, is Snell," one classifier flags every v5 server in the world.

v6 removes the shared signature. Every v6 deployment derives a unique protocol profile from its PSK — the salt scatter layout, the per-frame header-AAD lengths, the padding sizes, and the padding↔ciphertext interleave are all PSK-specific (see Snell v6). There is no contiguous salt, no fixed header offset, and no universal shaping rule to train on. A classifier built from one v6 server does not match the next one with a different PSK. v5 spends its bytes to share one shaped-but-recognizable look; v6 spends its bytes to give every deployment a different look.

That is a real improvement against the GFW's signature-based and machine-learned classifiers — there is no longer a single "this is Snell v6" rule to deploy.

2. "Block all unrecognized encrypted traffic" — v6 ≈ v5

The GFW also runs a cruder heuristic, documented in the Wu et al. USENIX Security 2023 paper How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic: flag streams that look fully random and match no known protocol (no TLS ClientHello, no HTTP, etc.).

Here v6 is in the same category as v5: both are non-TLS, high-entropy AEAD streams. v6 varies the structure per deployment, but it does not disguise itself as TLS/HTTPS or hide behind a CDN. Against a policy of "throttle or block anything we can't positively identify as a known protocol," v6 buys you nothing over v5 — neither one looks like something on the allowlist. Defeating that needs a transport wrapper (shadow-TLS / REALITY / domain fronting), which Snell does not natively provide.

3. Active probing — v6 ≈ v5 (slight edge)

When the GFW suspects an endpoint, it sends crafted or replayed bytes to see if it "answers like a proxy." Both v5 and v6 defend the same way: the server requires a valid AEAD tag derived from the PSK, and an invalid handshake is dropped silently with no response — a prober learns nothing.

v6 has a small edge: its first bytes are a scattered, structureless region rather than v5's contiguous salt followed by a sealed header at a fixed offset, so there is even less shape for an active fingerprinter to assert. But this is a refinement, not a category change — both already give a prober silence.

4. Replay and endpoint signals — unchanged

• Session replay. Neither v5 nor v6 has anti-replay (no timestamp window, no nonce cache). A censor that captures a full session and replays the bytes produces a valid session on both — the salt rides inside the captured bytes, so the server re-derives the same key. v6's salt scatter is obfuscation, not freshness; it does not add replay resistance. (This is the cryptographic age of the Snell protocol, shared by v4/v5/v6.)
• Endpoint-level analysis. IP reputation, traffic volume, connection timing, and destination correlation live below the protocol. v6 changes none of them. A single residential-IP endpoint moving steady high-volume encrypted traffic looks the same whether it speaks v5 or v6.

Verdict

Bottom line. v6 is the right answer to the question "the GFW learned to fingerprint Snell v5 — now what?" Its per-deployment diversity is purpose-built to deny a single classifier, which is the most common way a known proxy protocol gets blocked at scale. It is not an answer to "the GFW blocks everything that isn't recognizable TLS," and it does not fix the protocol's age (no replay protection).

Practical guidance:

• Prefer v6 over v5 if your concern is being caught by a Snell-specific classifier — that's the axis it improves.
• Use different PSKs across servers. v6's protection is the per-deployment diversity; reusing one PSK across many servers gives them a shared profile and throws away the main benefit.
• If your adversary blocks all unidentified encrypted traffic, no Snell version alone is enough — pair it with a TLS-mimicking transport, or see Comparison with Other Protocols for where Shadowsocks 2022 + REALITY/shadow-TLS fits.