What Is SSL Offloading?

Every HTTPS connection costs CPU cycles before a single byte of application logic runs. The TLS handshake, the symmetric encryption, the certificate checks all happen first. SSL offloading is the decision to do that work somewhere other than the application server.

A Proxy or Load Balancer Absorbs the TLS Handshake

In an offloaded setup, incoming HTTPS traffic hits a proxy or load balancer that holds the TLS certificate. That device negotiates the handshake, decrypts the request, and forwards it to the backend as plain HTTP over the internal network. The backend never touches a certificate or a cipher suite. It just reads a plaintext request.

This is why offloading is sometimes called SSL termination. Both terms describe the same event: encrypted traffic stops being encrypted at that hop.

Offloading Frees CPU and Centralizes Certificate Management

Two things get easier once TLS moves off the app servers. First, CPU that used to go into encryption math is now available for application code, which matters at scale when a fleet of backend instances would otherwise each be running their own handshake overhead. Second, certificates live in one place. Renewing a cert on ten backend servers is ten chances to get it wrong. Renewing it on one load balancer is one.

The tradeoff is the plaintext hop. Traffic between the load balancer and the backend server travels unencrypted unless something re-encrypts it. On a private network segment inside the same VPC or data center, that's usually an accepted risk. Across a public network, it isn't.

Offloading Is Not the Same as End-to-End Encryption

SSL offloading is a performance and operations decision, not a security posture. Once the load balancer decrypts the traffic, anything sitting between the load balancer and the backend can see it in plaintext if it's positioned to intercept it. For internal, trusted networks that's fine. For traffic carrying payment data, health records, or anything with a regulatory encryption requirement, offloading alone doesn't satisfy that requirement. That's the case for SSL passthrough instead, where the encrypted connection is never opened along the way.

Offloading Shows Up Anywhere a Proxy Sits in Front of an App

Load balancers (ALB, NLB, HAProxy, F5) are the most common place to see SSL offloading, but any proxy that terminates inbound HTTPS and forwards plain HTTP is doing the same thing. This includes reverse proxies like nginx, CDNs terminating at the edge, and API gateways. The pattern is identical: terminate here, forward plaintext there.

QuotaGuard Static's inbound proxy works this way: it terminates SSL on the inbound connection, routes the request, and forwards it to your app behind it. That's a different question from outbound traffic, where Static and Shield both carry HTTPS through a blind CONNECT tunnel and never decrypt the payload regardless of direction. The difference between offloading, passthrough, and termination matters most when you're deciding how a proxy should sit between your app and the outside world; see SSL Termination vs. SSL Passthrough vs. SSL Offloading for how those three terms map across inbound and outbound traffic.