Snell v6

Snell v6 (snell-server v6.0.0b1 / b2 / b3 / b4) is the latest generation of Surge's proxy protocol. We have fully reverse-engineered it and reimplemented it in Go — client and server, through the current v6.0.0b4 beta — with emission that is byte-for-byte identical to the official server on the wire.

What stayed the same

The inner request/response protocol and the cryptography are unchanged from v4/v5:

• KDF — Argon2id (t=3, m=8 KiB, p=1); the key is the first 16 bytes.
• AEAD — AES-128-GCM (12-byte little-endian counter nonce, 16-byte tag).
• Inner framing — the same 7-byte plaintext header, the same address encoding, the same multi-frame streaming in both directions.

What v6 added: a PSK-derived "protocol profile"

v6's headline feature is deployment-level protocol diversity. Every deployment derives a unique protocol profile from its PSK alone — no negotiation, and no version byte on the wire. Two servers with different PSKs speak measurably different-looking wire formats, which is what makes v6 hard to fingerprint as a class. The profile drives three new outer-layer behaviours, all keyed off the PSK:

1. Salt scatter

In v4/v5 the 16-byte AEAD salt is sent verbatim at the start of each direction. In v6 the salt is scattered into a larger, PSK-sized region: a PSK-derived permutation places the 16 salt bytes at pseudo-random offsets, XOR-masked with a PSK-derived keystream. The receiver runs the inverse permutation to recover the salt. There is no contiguous salt on the wire.

2. Per-frame header-AAD sizing

Each frame's sealed header is authenticated with a variable-length random "header-AAD" prefix, whose length is a PSK-derived function of the frame index. The length sequence H(0), H(1), H(2), … is deterministic per deployment, so the header offsets drift frame-to-frame in a PSK-specific pattern.

3. Per-frame traffic shaping

This is the big change. On top of the sealed payload, each frame carries:

• Padding — a PSK-derived amount of filler, sized so the frame reaches a per-deployment "write target". Small frames are topped up to plausible sizes; large frames pass through. The exact target is itself PSK-derived and varies per frame.
• A padding↔ciphertext interleave ("swap") — padding bytes and ciphertext bytes are exchanged according to one of several PSK-derived modes (a block swap, or a periodic single-byte swap with a keyed per-round phase). The receiver inverts the swap before it authenticates the frame.

The net effect: frame sizes and byte distributions are randomised per deployment, defeating the size/timing fingerprints that worked against the fixed v4/v5 framing.

b1 → b2 → b3 → b4

The betas evolved the internals and runtime more than the recipe:

v6.0.0b2 was wire-incompatible with b1 (the per-parameter hash changed). b3's default mode is the same shaped wire as b2 — its headline addition is the mode directive plus TFO-on-by-default.

v6.0.0b4 is a binary-only release: it refreshes all dependency libraries, fixes an internal robustness issue in UDP-forwarding mode (the wire-observable UDP behaviour is byte-identical to b2/b3), and removes the UPX shell so the binary now ships unpacked (~2.85 MB) to avoid extraction failures on certain servers — it is still statically linked. b4 is wire-identical to b3 (crypto, frame structure, padding/swap shaping and the mode selector are all unchanged), so OpenSnell interoperates with it unchanged and reports v6.0.0b4 as the latest v6.

So version = 6 should track the latest beta (b4); pinning b1/b2 selects an older, wire-incompatible build.

The mode directive (b3)

b3 adds a per-deployment encryption mode that must match between client and server (an empty/absent mode means default, matching the official server):

OpenSnell's Go client and server implement all three b3 modes byte-exactly; the unshaped and unsafe-raw paths simply skip the PSK-derived profile derivation since they carry no shaping.

Config changes (v5 → v6)

[snell-server]
listen = 0.0.0.0:8443
psk = a-16-to-255-byte-secret
dns-ip-preference = default
mode = default

Client side, bump the version (and set a matching mode if you changed it on the server):

ProxyName = snell, 1.2.3.4, 8443, psk = a-16-to-255-byte-secret, version = 6

What we built and validated

Against the unmodified official snell-server v6.0.0b4/b3 (and b2 in default mode, which shares the same shaped wire):

• Byte-exact emission. Our per-frame padding length matches the server's on every frame — 100% across 24 PSKs spanning every swap-mode and write-mode, for small and large frames alike — and full HTTP fetches plus multi-hundred-KB echoes interoperate for every PSK. On the wire, our traffic is indistinguishable from the official server's.
• All three b3 modes. default, unshaped, and unsafe-raw each interoperate with the official b3 binary in both directions.
• Performance on par with the hand-tuned C server. The frame hot path is allocation-free — each frame is built in one reused per-connection buffer with in-place AEAD sealing — so at the same throughput the Go server's per-byte CPU matches official b3, with lower memory.

Running v6 today

OpenSnell's open-source distribution stays v4/v5. For v6, the one-line installer can deploy the official Surge snell-server v6.0.0b4 (a statically-linked binary — no extra shared libraries):

bash <(curl -fsSL https://s.ee/opensnell)
# choose option 3 — Surge official snell-server v6.0.0b4

OpenSnell's own client can speak the v6 wire byte-for-byte, but — like the v6 server — that path is not part of the open-source build.