TLS termination is the point where an encrypted HTTPS connection is decrypted back into plain traffic. In a simple setup, that's your web server itself. In many real-world architectures, it happens earlier — at a load balancer, reverse proxy, or CDN — with traffic continuing to your actual origin server over a separate, sometimes unencrypted, internal connection.
Why this architecture is common
Terminating TLS at a load balancer or CDN centralizes certificate management (one place to install and renew certificates instead of many backend servers) and offloads the encryption/decryption CPU work from the application servers themselves. This is exactly what's happening when you set a CDN like Cloudflare to "Flexible" or "Full" SSL mode — those settings control whether the connection from the CDN to your actual origin server is also encrypted.
The security implication worth understanding
If TLS terminates at a proxy and the connection onward to your origin server is plain HTTP, that internal hop is unencrypted — usually an acceptable trade-off if it stays within a trusted private network, but a real gap if that internal traffic crosses the public internet. This is also the root cause of many of the redirect-loop issues covered in our HTTPS Migration guides — the origin server sees an incoming plain-HTTP request from the proxy and tries to redirect it, even though the original visitor connection was already secure.
Why centralizing termination at a proxy simplifies certificate management considerably
Terminating TLS at one load balancer or CDN, rather than on every individual backend server, means certificate installation and renewal only needs to happen in one place — a meaningful operational simplification once you're running more than a single backend server behind that shared entry point.
The security question this architecture always raises: is the internal hop also encrypted
Once TLS terminates at a proxy, the connection onward to your actual origin server is a separate decision — plain HTTP is a reasonable trade-off if that hop stays within a trusted private network, but a real gap if it crosses the public internet, which is exactly what settings like Cloudflare's Full versus Flexible SSL modes control.
Why this architecture decision is invisible to visitors but significant for operators
A visitor has no way to tell from the browser alone whether TLS terminated at your origin server directly or at an intervening CDN or load balancer, both look identical as a valid HTTPS connection, but the distinction matters considerably for whoever operates the infrastructure, since it determines where certificate management and encryption actually happen internally.
Why cloud load balancers almost universally default to terminating TLS at the edge
Terminating TLS at a managed load balancer centralizes certificate management in one place integrated with the cloud provider's own certificate service, and offloads encryption overhead from backend application servers — this combination of operational simplicity and performance benefit is why it's the default architecture most cloud platforms guide users toward.
What SSL passthrough means as an alternative architecture
Rather than terminating TLS at the load balancer, passthrough mode forwards the encrypted connection unchanged all the way to the backend server, which then handles decryption itself — this provides genuine end-to-end encryption at the cost of losing the load balancer's ability to inspect or route based on the request content.
Why this architectural detail is worth understanding even if you never configure it yourself
Knowing where TLS actually terminates in your specific infrastructure is often the single fastest way to correctly diagnose a redirect loop or an unexpected certificate mismatch, since so many real-world issues trace directly back to a mismatch between where a request is decrypted and where the application assumes it was.
What a decision framework looks like for choosing where to terminate TLS in your own architecture
Weighing operational simplicity (centralized termination) against end-to-end encryption requirements (termination at the origin, or re-encryption after an intermediate termination point) is the core trade-off — for most applications without specific compliance requirements demanding end-to-end encryption, centralized termination at a load balancer or CDN remains the simpler, generally recommended default.
A closing thought
A quick closing thought: knowing exactly where TLS terminates in your own infrastructure is often the single fastest starting point for diagnosing a confusing redirect or certificate mismatch elsewhere on this site.