What Is SSL Passthrough?

Passthrough answers a specific question: what if the device sitting in the middle of a connection isn't supposed to be able to read it? SSL termination assumes the intermediary can see the traffic. Passthrough removes that assumption entirely.

The Intermediary Routes Packets Without Opening the Connection

In a passthrough setup, the load balancer or proxy reads only what it needs to route the traffic, typically the destination host from the TLS handshake's SNI (Server Name Indication) field, which is sent unencrypted before the rest of the session is established. It uses that to pick a backend, then forwards the encrypted bytes untouched. The actual TLS handshake, the one that produces the session keys, happens directly between the client and the backend server. The intermediary never holds the private key for that connection and never sees the decrypted payload.

Passthrough Trades Visibility for a Real End-to-End Guarantee

Because the intermediary can't decrypt the traffic, it can't do anything that requires reading the request: no header-based routing, no payload inspection, no web application firewall rules that look inside the body. Load balancing decisions are limited to whatever's visible before decryption, mainly the SNI hostname and the source IP.

What passthrough buys back is a guarantee that termination can't offer: nothing between the client and the final server ever had the plaintext, not even for a moment. For workloads where that's a hard requirement, regulated data, client certificate authentication that needs to reach the actual destination, contractual no-third-party-decryption clauses, passthrough is the only architecture that satisfies it.

Passthrough Requires the Backend to Handle Its Own TLS

Since the intermediary never terminates the connection, the backend server has to hold its own certificate and do its own handshake. This removes the centralized certificate management that comes with termination. Every backend that needs to receive passthrough traffic needs its own valid certificate, and renewing certs is now a per-server task again instead of a single point of update.

This is the model QuotaGuard Shield uses for outbound traffic: the TLS session runs directly between the customer's application and the destination server, and QuotaGuard's proxy routes the connection without ever holding the keys or decrypting the payload. QuotaGuard Static behaves the same way for outbound; the routing decision on both products is made from the CONNECT request, not from inspecting encrypted content. See SSL Termination vs. SSL Passthrough vs. SSL Offloading for the full breakdown of how this applies across inbound and outbound traffic.