One ingress, one owner: Caddy routing is not authorization

A hostname chooses a route. It does not identify a person.

A reverse proxy needs routing information. For HTTP, the requested host is one of the most useful inputs: it lets one listener serve several applications.

That same property creates a common mistake. A matching Host header proves only that the request selected a route. It does not prove that the request came through the identity-aware edge, that the caller is an approved user, or that the backend could not have been reached another way.

The distinction matters most when an application is intended to be protected by an upstream login gate. If the proxy listener can be reached around that gate, a caller may still be able to select the protected virtual host with a host header. Routing has worked exactly as designed; authorization has not happened.

One ingress makes the exceptions visible

I use one owned reverse-proxy boundary for application web traffic. Applications bind to a private network or a loopback-only listener, while the proxy owns the approved external listener, TLS behavior, route inventory, and request logs.

That arrangement does not magically secure every service. It makes the questions visible:

• Which component owns this listener?
• Which route is approved for this application?
• Which identity control applies before the route is reached?
• Can the backend be contacted directly from an untrusted network?
• What happens if the proxy, the upstream, or the identity provider fails?

Each exception should be written down. Database protocols, monitoring agents, and private administrative tools may have different transport needs. Calling them part of the web ingress without documenting the difference only hides the work.

Keep the backend private first

The strongest route policy is easier to reason about when the backend has no untrusted listener of its own. Prefer a private container network or a loopback-only bind. Then allow the proxy to reach it through one intended path.

This changes a browser-facing review from “which of many ports might expose the application?” to “does the proxy route exist, and does the backend remain private?” It also makes route removal safer: removing the proxy rule should remove the reachable application path rather than merely hide a URL.

Forwarded headers need an explicit trust chain

When another proxy or CDN sits in front of Caddy, request headers can carry client-address or identity-related context. Those headers are meaningful only when Caddy knows which immediate peers may supply them.

Caddy documents trusted_proxies for this purpose and defaults to trusting no proxy ranges. Its reverse-proxy handler also ignores spoofed incoming X-Forwarded-* values by default unless the proxy is trusted. Configure the specific trusted chain, not a broad convenience range, and test an untrusted request that supplies the same headers. Caddy's proxy documentation and global options reference describe the relevant behavior.

Identity headers need the same discipline. Strip or validate them at the boundary; do not let an arbitrary direct caller present a header that the backend treats as a logged-in identity.

Test the route from the wrong side too

An ingress change is not complete when the configuration parses or the proxy process is healthy. I would test at least four paths:

Caddy supports active and passive upstream health checks, which are useful for proxy behavior. They do not prove the user workflow behind the upstream is working. Keep a separate end-to-end check for the actual application contract.

A controlled front door is an operational advantage

One ingress also concentrates routine work: certificate state, validation before reload, structured logs, rollback, and the inventory of published routes. That makes it easier to answer how a service is exposed and easier to notice a proposed exception.

The claim should remain modest. Caddy is a routing and proxy boundary. It is not an identity provider, an application permission system, or a substitute for network isolation. Give every web listener one owner, keep its backend private, and prove the negative path. That is how routing becomes useful evidence rather than a comforting diagram.