A reverse proxy represents one or more servers to clients. Visitors connect to the proxy's public endpoint; it selects an application server, forwards the request and returns the response.
Common responsibilities
- TLS certificate handling
- Load balancing and health checks
- Static response caching
- Routing by host or path
- Rate limits and security headers
Trust forwarded headers carefully
Applications often need the original client address and scheme. Only accept forwarding headers from trusted proxies; otherwise a client can forge them.
Not a complete security boundary
A reverse proxy can reduce direct exposure of application servers, but vulnerable application logic remains vulnerable. Patch the origin, restrict origin access and log both proxy and application events.
A forward proxy acts for clients; a reverse proxy acts for servers. That perspective is the simplest reliable distinction.
Protect the origin
If attackers can reach the application server directly, they may bypass proxy rate limits and access rules. Restrict origin traffic to trusted proxy networks, authenticate proxy-to-origin connections and ensure health endpoints reveal little.
Design for failure and investigation
Health checks must represent real readiness without exposing sensitive details. Test timeouts, body limits, retry behavior and certificate renewal. Automatic retries on non-idempotent requests can duplicate purchases or jobs, so routing policy needs application context.
Carry a request identifier through proxy and application logs while avoiding secrets in URLs and headers. A reverse proxy centralizes useful controls, but it also concentrates failure. Keep a rollback path and test direct origin access from both allowed and forbidden networks.
When adding a CDN or web application firewall, document which layer owns redirects, compression and caching. Conflicting rules can create loops or cache private responses even when each configuration looks reasonable by itself.