A reverse proxy sitting in front of one or more backend application servers needs its own certificate configuration, independent of whatever the backend applications themselves are doing — the same TLS termination pattern covered elsewhere in this category, with two common tool choices worth comparing.
Nginx: manual but flexible
Configure a server block for port 443 with your certificate, and a proxy_pass directive forwarding requests to your backend application — giving you full control over every aspect of the TLS configuration, at the cost of needing to manage certificate issuance and renewal yourself (typically via Certbot).
Caddy: automatic by default
yourdomain.com {
reverse_proxy localhost:3000
}Caddy automatically obtains and renews a certificate from Let's Encrypt for any domain in its configuration, with zero additional SSL-specific configuration required — this single block is in practice a complete, working HTTPS reverse proxy setup, which is a meaningful simplification compared to the equivalent Nginx-plus-Certbot setup for anyone who doesn't need Nginx's finer-grained control.
What to do if Caddy's automatic HTTPS isn't working for your domain
Caddy's automatic certificate provisioning requires your domain's DNS to already point to the server before Caddy starts, since it performs its own ACME validation automatically — confirming DNS is correctly configured and propagated before starting Caddy resolves most automatic HTTPS issues.
How Caddy's approach to automatic HTTPS differs philosophically from Nginx's manual configuration
Caddy treats automatic, zero-configuration HTTPS as its core design philosophy, requiring essentially no explicit TLS configuration for a standard setup, while Nginx requires explicit certificate paths and configuration directives — a genuine trade-off between Caddy's convenience and Nginx's more explicit, granular control.
What on-demand TLS means as an even more automated Caddy configuration option
Caddy's on-demand TLS mode can provision certificates for domains not even known in advance at configuration time, issuing them dynamically on a domain's first incoming request — useful for platforms hosting many customer-provided custom domains without needing to pre-configure each one.
How to migrate an existing Nginx-based reverse proxy setup to Caddy if desired
Migrating from Nginx to Caddy generally involves translating your existing server block logic into Caddy's simpler Caddyfile syntax and removing manual certificate configuration entirely, since Caddy handles that automatically — a worthwhile exercise exactly if your current Nginx configuration is primarily basic reverse proxying without highly specialized, Nginx-specific features.
Why choosing between Nginx and Caddy often comes down to configuration philosophy rather than capability
Both can achieve equivalent end results for most reverse proxy and TLS termination needs — the choice more often reflects whether you value Caddy's convention-over-configuration simplicity or Nginx's more explicit, granular control and larger existing body of documentation and community knowledge.
What to do if your reverse proxy successfully gets a certificate but backend connections fail
A successfully issued proxy certificate with failing backend connections points to an issue in the proxy-to-backend hop in particular, not the certificate itself — checking your proxy's backend connection configuration (correct backend address, correct port, expected protocol) isolates this as a distinct issue from the TLS-facing side of the proxy.
How to add multiple backend services behind a single reverse proxy with HTTPS
Configuring path-based or hostname-based routing rules in your reverse proxy lets one HTTPS-terminating proxy route different requests to different backend services, consolidating certificate management to one place while still serving multiple distinct backend applications.
A closing note on reverse proxy TLS as a foundational pattern worth understanding well
The reverse-proxy-with-centralized-TLS pattern covered in this guide underlies a large share of modern web infrastructure — understanding it well pays dividends across container deployments, cloud infrastructure, and traditional server setups alike, since the same underlying principle recurs throughout this site's other guides.
Loading comments…