Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Snell

Snell is a lean encrypted proxy protocol developed by our team. Here are some highlights:

  • Extreme performance.

  • Support UDP over TCP relay.

  • Single binary with zero dependencies. (except glibc)

  • A wizard to help you start.

  • Proxy server will report remote errors to the client if an error encounters. Clients may choose countermeasures for different scenarios.

https://dl.nssurge.com/snell/snell-server-v5.0.1-linux-amd64.zip
https://dl.nssurge.com/snell/snell-server-v5.0.1-linux-i386.zip
https://dl.nssurge.com/snell/snell-server-v5.0.1-linux-aarch64.zip
https://dl.nssurge.com/snell/snell-server-v5.0.1-linux-armv7l.zip

Snell is a proxy protocol designed with performance as its primary objective. As a deliberate design trade-off, it omits certain security properties and uses lighter-weight cryptographic parameters where the associated overhead would have a measurable impact on performance.

If your primary goal is maximizing security guarantees rather than minimizing overhead, we recommend using a TLS-based proxy protocol instead. Snell is designed for users who are willing to make carefully considered security-performance trade-offs in exchange for lower latency, lower resource consumption, and higher throughput.

Security Technical Details

The following design choices should be understood as deliberate performance-security trade-offs rather than weaknesses in the protocol.

For example, Snell does not provide forward secrecy. Achieving forward secrecy requires an ephemeral key exchange so that session keys are not derived solely from long-term secrets. Because Snell is designed as a 0-RTT protocol, application traffic can be authenticated and encrypted immediately using only a pre-shared key. Providing forward secrecy would therefore require an additional key-exchange phase before application data could be protected, increasing connection-establishment latency and protocol complexity.

Similarly, Snell does not implement a dedicated replay-protection mechanism. Replay protection is not a universal property of Internet protocols, and many widely deployed protocols operate securely without maintaining anti-replay state. Furthermore, some proxy protocols historically associated with replay-based identification were primarily affected by the lack of authenticated encryption and integrity protection rather than the absence of replay protection itself. Snell uses authenticated encryption (AEAD) throughout the protocol, ensuring that modified or forged traffic is rejected.

For the same reason, the parameters used by Snell’s PSK key derivation function are intentionally tuned to reduce computational cost compared to more conservative security-focused configurations. Even with these reduced parameters, brute-force attacks remain impractical when a sufficiently random PSK is used. In practice, a randomly generated PSK of 12 or more characters already provides a security margin far beyond the reach of exhaustive search. We recommend using the 32-character random PSKs generated by the snell-server setup wizard, which provide an extremely large margin against brute-force attacks even under highly optimistic assumptions about attacker capabilities. Even assuming an attacker could verify one quintillion (10^18) candidate keys per second, exhaustively searching the entire key space would still take roughly 10^31 years.

Release Notes

v6.0.0 Beta

Snell v6 features PSK-derived deployment-level protocol diversity that generates unique traffic characteristics for each deployment, significantly reducing reliance on a single protocol fingerprint while preserving Snell’s core goals of performance, deployment simplicity, accurate error reporting, and full TCP semantics. Snell v6 also removes QUIC Proxy Mode, adds new IPv4/IPv6 network stack controls including dns-ip-preference and multi-address listen support, and is currently available for beta testing.

Please check our blog for more information.

Beta 2 Updates

  • Fixed an issue that performance unexpectedly dropped significantly.

  • Fixed an issue with external dynamic dependency libraries.

Please note that this version adjusts the protocol profile, so Surge Mac also needs to be updated to the latest version.

Beta 3 Updates

Snell v6 beta 3 has added a mode setting.

  1. mode=default Default mode, enables traffic obfuscation and AES encryption.

  2. mode=unshaped Disables obfuscation and uses only AES encryption. Compared with the default mode, throughput performance can be improved by about 10%. This mode is equivalent to Snell v3, where the encrypted traffic appears completely random.

  3. mode=unsafe-raw Disables encryption and obfuscation, forwarding all traffic in plaintext. It should only be used in secure network environments, such as an intranet or under another secure tunnel.

Please note that the server mode and client mode must be consistent.

Beta 4 Updates

  • Fixed some potential issues in UDP forwarding mode.

  • Upgraded all dependency libraries to the latest versions.

  • Removed UPX shell to avoid failure to run in certain server environments.

RC Updates

  • Fix the issue where the first few UDP packets may be truncated when forwarding starts.

RC2 Updates

  • When ipv6=false, return a clearer error message when the client explicitly accesses an IPv6 address.

v5.0.1

  • Fixed a low-probability crash caused by an assertion.

v5.0.0

Dynamic Record Sizing

This feature will improve latency performance under network environments with packet loss. For technical details, refer to: Cloudflare Blog

QUIC Proxy Mode

Snell v5 introduces a special QUIC Proxy mode designed for QUIC traffic. This mode works as UDP over UDP to avoid TCP over UDP issues. (The server needs to open a UDP port.)

  • This working mode is specially optimized for QUIC. It is only enabled when Surge detects QUIC traffic; other UDP traffic still uses the UDP over TCP mode.

  • QUIC Proxy will only strongly encrypt the QUIC Handshake packets to protect SNI and target hostnames, while also performing authentication. All subsequent QUIC packets, already strongly encrypted by QUIC itself, will be forwarded as raw packets, greatly reducing unnecessary encryption and decryption overhead. Additionally, since no extra bytes are introduced, QUIC's PMTU probing will not be affected.

Egress Control

  • Supports configuration of the egress-interface parameter to control the egress interface (requires root privileges or CAP_NET_RAW/CAP_NET_ADMIN license, and the interface must have routing tables for the target address and DNS).

  • Supports systemd's Socket Activation mechanism, which can be used to configure network namespaces as well as for egress interface profile. We will provide configuration examples later.

The Snell v5 server is backward compatible with v4 clients. If you do not wish to use the QUIC Proxy Mode feature, set the client to v4. The Dynamic Record Sizing optimization only relates to the server.

v4.1.1

  • Fix a potential crash that may occur during UDP forwarding.

v4.1.0

  • Add a dns parameter for customizing DNS server addresses, supporting multiple address configurations.

  • Update the DNS library c-ares to the latest version to resolve compatibility issues with specific DNS records.

  • Add output of the currently used DNS server at startup.

  • Adjust log output to lower broken pipe error messages to verbose level.

  • Update libuv to v1.48.0 to fix potential crashes when accessing IPv6 addresses on certain systems.

  • Improve log information for DNS errors.

  • Fix an issue where certain invalid DNS records could cause a crash.

v4.0.1

Fixed a bug that UDP packets can't be forwarded to IPv6 addresses.

Surge Mac as Snell Proxy Server

You may also use Surge Mac as a Snell proxy server (Starting from version 3.1.0). Add the following lines to your profile.

The embedded Snell server in Surge uses the Snell V1 protocol.

PreviousSurge Mac Legacy Versions

Last updated