Terminate TLS at the proxy when the network behind it is one you fully control and monitor. Re-encrypt to the backend when traffic crosses shared or untrusted networks, or when a rule requires encryption in transit end to end. Pass through when the proxy must never see plaintext.
The three patterns
Terminate only. The proxy decrypts, inspects and forwards plain HTTP to the backend. Simple, cheap, and the proxy can apply rate limits, a WAF and header rules. The backend hop is unencrypted.
Terminate and re-encrypt. The proxy decrypts, then opens a new TLS connection to the backend. You keep inspection and add confidentiality on the second hop.
Pass through. The proxy forwards the encrypted stream by hostname or address without decrypting it. The backend holds the certificate. The proxy cannot read headers, so no path based routing, no WAF, and limited logging.
Questions to decide
- Who can see the network between proxy and backend? Same host or private link you control is different from a shared cloud network, a cluster overlay or another provider.
- Is there a requirement? Some compliance programs and customer contracts ask for encryption in transit inside your environment. Check the actual text before assuming.
- Do you need to inspect traffic? If rate limiting, WAF rules or caching matter, you need to terminate.
- How do you manage certificates on many backends? Re-encryption adds certificates to renew. See the wildcard versus per host certificates guide.
- Do you want the backend to know the client? After terminating, the backend sees the proxy's address unless you pass it along, carefully.
What you lose when you terminate
The backend no longer sees the client's TLS details, so it cannot tell the original scheme without a header. Set X-Forwarded-Proto and make the application honor it for secure cookies and redirect URLs. See secure cookie flags. The backend also loses client address unless the proxy forwards it, and then the backend must trust that header only from the proxy. The nginx and Caddy posts in this series cover that, for example nginx real_ip.
Re-encryption must verify
Encrypting the second hop without verifying the certificate protects against eavesdropping but not impersonation. In nginx, proxy_ssl_verify defaults to off, so the proxy accepts any certificate presented by the backend unless you turn it on and supply a trusted CA file. Caddy verifies by default for https upstreams and documents tls_insecure_skip_verify as not for production. Whatever the proxy, confirm that verification and a hostname check are on. For service to service identity, mutual TLS goes further.
A simple rule of thumb
- Single host or private socket: terminate only.
- Shared network, or a stated requirement: re-encrypt with verification.
- Must not decrypt at the edge: pass through, and accept the lost controls.
Write the choice down with the reasoning, so a reviewer can see it was a decision.
Where Safeguard fits
Safeguard handles compliance and evidence automation, so you can keep records of such decisions alongside controls, plus dependency scanning for the software on both sides. Start with the free scan at https://gold.safeguard.sh/scan.
Quick check
Is terminating TLS at the proxy insecure?
Not by itself. It is acceptable when the network behind the proxy is controlled and monitored. Re-encrypt when it is not.
What does pass through give up?
The proxy cannot read requests, so it loses path routing, WAF rules and detailed logs.
Sources
Last reviewed: 19 October 2026.
