Use with Surge (QUIC / HTTP-3)

The native Go client in this repo speaks SOCKS5; it does not speak QUIC. For HTTP/3 acceleration through OpenSnell, the recommended front-end is Surge, which knows how to construct the v5 QUIC envelope and hands raw QUIC to the server after the first packet.

Surge proxy line

In your Surge config, add the server as a snell proxy with version=5 and disable Surge's per-connection QUIC block:

[Proxy]
my-snell = snell, your-server.example.com, 2333, psk=your-shared-secret, version=5, tfo=true, block-quic=off

The important bits:

What happens on the wire

When Surge dispatches an HTTP/3 connection through my-snell:

1. It wraps the first 1–2 QUIC Initial packets in the snell envelope (containing the target SNI/host, so it's hidden on the wire) and sends them to UDP/<port> on the OpenSnell server.
2. OpenSnell's ServeQUIC loop decrypts the envelope, parses the (host, port) from the request header, opens a UDP socket to that upstream, and records the (client_src, upstream) mapping.
3. Every subsequent UDP packet — in either direction — is forwarded as raw QUIC with no additional snell framing. Surge and the destination server complete their QUIC handshake end-to-end with OpenSnell as a transparent relay.

See the QUIC mode page for the full envelope layout and the reverse-engineering story.

Firewall

QUIC mode requires both TCP/<port> (for the snell TCP path) and UDP/<port> (for the QUIC envelopes) open between Surge and the OpenSnell host. The installer takes care of this for UFW / firewalld; if you manage the firewall manually, you need both rules.

Verifying it works

A quick way to confirm HTTP/3 actually went through the QUIC path, rather than falling back to TCP:

1. Set block-quic=off on the proxy line as shown above.
2. Open Surge → Activity → filter by your proxy. HTTP/3 connections show up with protocol QUIC rather than HTTP/2 or HTTP/1.1.
3. From the OpenSnell server logs (with -v), you should see ServeQUIC entries with the SNI/host extracted from the snell envelope.