TLS Passthrough vs. TLS Termination: Choosing Where Encryption Ends

"SSL" and "TLS" describe the same protocol family in everyday use; SSL is the deprecated predecessor, TLS is the current standard, and most engineers say SSL out of habit when they mean TLS. The termination-versus-passthrough decision is identical under either name: does the connection stay encrypted all the way to the real destination, or does something in the middle end it first.

Termination Ends the Connection at an Intermediary

With TLS termination, a load balancer, proxy, or CDN edge node holds the certificate and completes the handshake. It sees the request in plaintext and decides what to do with it: forward it as-is on a trusted internal network, re-encrypt it for the next hop, or act on it directly. Termination is what makes header-based routing, path-based rules, and payload inspection possible, because all of those require reading the decrypted request.

Passthrough Keeps the Connection Intact to the Final Server

With TLS passthrough, the intermediary routes the connection using only what's visible before decryption, mainly the SNI hostname, and forwards the encrypted bytes without opening them. The handshake happens directly between the client and the actual destination server. Nothing in between ever holds the session keys or sees the plaintext.

The Choice Comes Down to Who Needs to Read the Traffic

Pick termination when something in the path needs to make decisions based on the request content: a web application firewall inspecting payloads, an API gateway routing by path or header, a CDN caching based on URL. Pick passthrough when the requirement is that nothing but the two endpoints ever sees the plaintext, which is common for regulated data, client certificate authentication that has to terminate at the real server, and contractual language that rules out third-party decryption.

There's no universally correct answer. A payments API might need passthrough for the card data path and termination for its public marketing site on the same infrastructure. The decision is made per connection, not per company.

QuotaGuard maps to both sides of this depending on direction. Static's inbound proxy terminates TLS to route requests to your app. For outbound traffic, both Static and Shield use a passthrough-style model: HTTPS is carried through a blind CONNECT tunnel, and the proxy routes based on the destination host and port without ever decrypting the payload. Shield adds TLS on the customer-to-proxy hop itself, which Static leaves in plaintext; that's the actual product difference, not which one decrypts your data. This closes out the cluster; see SSL Termination vs. SSL Passthrough vs. SSL Offloading for the full picture across every term in this series.