A layer-4 proxy routes incoming HTTPS connections to different backends without ever decrypting them. What information in the TLS ClientHello makes that possible, and which routing decisions remain off the table?

## Why anything is readable at all A TLS connection cannot begin encrypted: the two ends have not yet agreed on keys. The client's opening message therefore travels as cleartext, and it must state enough for the server to answer. Two of the extensions it carries are useful to a proxy in the middle: - **SNI (Server Name Indication)** — the hostname the client intends to reach. It exists because one IP address and port can host many sites, and the server must know which certificate to present before it can present one. - **ALPN (Application-Layer Protocol Negotiation)** — the list of application protocols the client is willing to speak, using registered identifiers such as `h2` for HTTP/2 and `http/1.1`. A proxy that reads these has enough to choose a destination without possessing any key: peek at the first bytes, pick a backend pool, then splice the two sockets and copy bytes for the rest of the connection's life. ## What that design gives you The practical wins are exactly the two extensions. Many hostnames share one listening address, each routed to its own backend, with certificates and private keys living only on those backends. And a single port can serve mixed protocols: HTTP/2 traffic to one pool, HTTP/1.1 to another, or a non-HTTP protocol that happens to be wrapped in TLS to a completely different service. It is also the mode with the lowest CPU cost per byte, because nothing is decrypted, re-framed or re-encrypted — the proxy is doing little more than a socket copy. ## What is off the table Everything above the record layer. There is no path, no method, no `Host` header, no cookie, no `Authorization` header, no request or response body — those all appear only after the handshake completes, encrypted. Under TLS 1.3 even the *server's* certificate is encrypted, so a passthrough proxy cannot inspect the certificate the origin presented; in TLS 1.2 that message was in the clear, which is a difference worth knowing when reading older material or packet captures. The deeper consequence is granularity. The routing decision is made once, per connection, before any request exists: - No path-based or header-based routing, and no rewriting. - No inserting or stripping headers, so the client's address must be conveyed by other means or not at all. - No caching, no compression, no request-body inspection. - No per-request load balancing and no per-request retry: with keep-alive or HTTP/2, one connection can carry hundreds of requests to the one backend chosen at the start, and if that backend degrades mid-connection the proxy cannot move the next request elsewhere. - Health information is limited to whether the TCP connection can be established, unless the proxy runs separate probes. ## SNI is an assertion, not a fact The client writes SNI itself, before anything has been authenticated. It is fine as a routing key — the worst a lying client achieves is being sent to a backend whose certificate then fails its own validation — but it must never be treated as an authorization decision or as proof of intent. Two related mismatches matter. First, SNI and the later HTTP authority are chosen independently by the client and can disagree, which is why a terminating server should check that the request's authority matches the name it served a certificate for. Second, a proxy routing on SNI is routing on a name nobody has verified, so security policy belongs at the terminating endpoint, not at the splice point. ## The version-dated caveat SNI's visibility is what makes this whole technique work, and it is also a privacy leak: any observer learns which site you asked for. Encrypted Client Hello (ECH) exists to close that, encrypting the sensitive parts of the ClientHello to a public key published in DNS. As of 2026 it is deployed by some browsers and CDNs but is still not universal, and where it is in use an SNI-routing proxy loses the field it depended on — either it is the ECH-terminating endpoint holding the decryption key, or it cannot see the name. Any answer here should say "as of" and note that this is moving. ## Recognising it in practice You can see exactly what a client offers by making a connection with the server name and protocol list set explicitly and reading the handshake trace. If a proxy sends you to the wrong backend, the first thing to check is which name the client actually put in SNI — clients that connect by IP address, or older tooling, may send no SNI at all, which usually lands on the proxy's default backend and produces a confusing certificate mismatch.