Reverse proxy

What it means

A reverse proxy is a server-facing intermediary: visitors connect to it, and it forwards eligible requests to an upstream service such as an application server. Unlike a forward proxy configured by a client, this one is deployed in front of services the site operator controls. It can route by hostname or path, manage connections, and optionally terminate TLS. Caddy reverse proxy

The proxy is not the application. It can serve as a stable public entrance while an app listens privately, but the result depends on actual configuration and upstream health. Adding a single reverse proxy is not, by itself, high availability.

Try it

Example — one public route and two internal destinations. The following illustrates intent, not executable production configuration or evidence of a real service.

Browser
  |
  | HTTPS: www.example.com
  v
Public reverse proxy
  |-- /api/*  --> application upstream
  +-- /      --> static-content upstream

The reverse proxy receives the request, evaluates its routing rules and passes it to the selected upstream. The public hostname can stay the same while the internal destination differs. The upstream returns a response that the proxy may forward, amend or replace according to configuration. A routing typo can point at the wrong service even if the proxy itself is reachable.

What the proxy can and cannot do

Caddy documents upstream selection, transports, header controls and health checks as configurable features, not automatic guarantees. Forwarded headers such as X-Forwarded-For can be spoofed if an application trusts arbitrary clients; define which proxy hops are trusted. Header handling

How to reason about a failure

1. Is the public hostname resolving and the public TLS handshake valid? If not, investigate before application routing.
2. Does the proxy route this exact hostname and path? A missing rule may return 404 even while the upstream is healthy.
3. Is the intended upstream reachable from the proxy, listening on the selected socket and producing valid HTTP responses? A failing connection can surface as a proxy error.
4. Do logs on the proxy and application agree on a sanitized request ID, time window and status? Remove tokens and personal data from any shared traces.
5. If TLS is terminated twice, verify the upstream certificate independently. Do not turn off certificate verification as an expedient fix.

In practice

A reverse proxy is useful for isolating application processes from the public network, routing several services under one site and standardizing TLS policy. It also creates an extra dependency to monitor. Pair this mental model with HTTP 502 troubleshooting for upstream failures, HTTP 404 troubleshooting for route mismatches, and CDN for a separate edge-delivery role.