Reverse Proxy Fundamentals
A reverse proxy is a server that accepts requests on behalf of one or more backend servers, chooses where each request goes, and returns the backend response. It gives clients one public endpoint while keeping backend addresses and traffic rules behind that boundary.
itWeb servers, proxies, and traffic management | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Reverse Proxy Fundamentals
A reverse proxy is the doorman for a service that has decided its backends should not answer the public door directly. A client talks to the proxy as if it were the origin server. The proxy then decides where the request goes and returns the answer. This sounds like a small administrative detail, which is how it gets enough responsibility to become interesting.
Before this boundary exists, a public name points at one server and that server must do everything visible to the client. With the proxy in front, the public name can stay put while backend addresses, ports, and server counts move around behind it. The proxy can also route by host or path, terminate TLS on the client-facing connection, select a healthy backend, cache eligible responses, and record traffic. It is not magic. It is a place to put decisions.
The important shape is two connections, not one. There is a client-facing connection from the client to the proxy, then a backend-facing connection from the proxy to the selected server. TLS termination therefore ends one protected connection; it says nothing by itself about the next one. Likewise, the backend usually sees the proxy as its immediate peer, not the original client. This is where a surprising amount of confident configuration turns into a very polite misunderstanding.
A route is the proxy's answer to “where does this request belong?” Layer four routing uses connection information such as address and port. Layer seven routing can use HTTP data such as host and path. Use the smallest layer that can make the decision. Specific routes need predictable precedence, and an unknown host should fail safely. Otherwise a request can arrive at a real application merely because the configuration ran out of ideas.
The second idea is that proxy behavior changes HTTP behavior unless you constrain it. A rewrite, timeout, retry, cache key, or forwarded header is policy. A backend pool can distribute requests and health checks can remove a failed target, but neither adds capacity or makes one proxy redundant. A retry can also repeat work that a backend already processed, which is a bad moment for optimism.
Start with the cheatsheet when you need the moving parts and the failure signals in one place. The slides make the request path and routing choices easier to compare. The practice reference then gives you a local listener and backend to inspect, while the exercise makes one listener route to two backends. The reference tab is where the precise protocol and product behavior waits, patiently, with considerably less charm.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.rfc-editor.org/rfc/rfc9110.html
Supports
- Reverse proxy, forward proxy, gateway, tunnel, upstream, downstream, inbound, and outbound definitions
- HTTP method semantics, intermediary behavior, connection handling, field processing, and safe retry considerations
- https://www.rfc-editor.org/rfc/rfc7239.html
Supports
- Forwarded field parameters for client-facing node, proxy interface, host, and protocol
- Proxy-chain ordering, field integrity limits, privacy risks, and trusted-proxy requirements
- https://www.rfc-editor.org/rfc/rfc9111.html
Supports
- Shared-cache behavior, cache keys, freshness, validation, invalidation, and authenticated-response constraints
- https://www.rfc-editor.org/rfc/rfc9209.html
Supports
- Standard proxy error types, generated-by identification, diagnostic parameters, and security considerations
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling
Supports
- Learner-oriented comparison of forward proxies, reverse proxies, and tunnels
- https://nginx.org/en/docs/http/ngx_http_proxy_module.html
Supports
- Backend selection, request URI mapping, request field defaults, buffering, timeouts, caching, and protocol upgrade configuration
- https://nginx.org/en/docs/http/request_processing.html
Supports
- Listener and server-name selection, default servers, and rejecting undefined host names
- https://docs.nginx.com/nginx/admin-guide/monitoring/logging/
Supports
- Access and error logging, upstream timing variables, conditional logging, and runtime diagnostics
- https://www.haproxy.com/documentation/haproxy-configuration-tutorials/proxying-essentials/configuration-basics/
Supports
- Client-facing frontends, backend server pools, combined listeners, and proxy configuration structure
- https://www.haproxy.com/documentation/haproxy-configuration-tutorials/proxying-essentials/configuration-basics/frontends/
Supports
- Layer four and layer seven modes, bind addresses, default backends, and conditional host routing
- https://www.haproxy.com/documentation/haproxy-configuration-tutorials/reliability/health-checks/
Supports
- Active and passive health checks, backend eligibility, probe configuration, status, and diagnostics
- https://github.com/sindresorhus/awesome
Supports
- Required discovery starting point for curated awesome lists
- https://github.com/awesome-foss/awesome-sysadmin
Supports
- Discovery path from the sysadmin list to the current Web Servers and Reverse Proxies catalog
- https://awesome-selfhosted.net/tags/web-servers.html
Supports
- Current curated listing of Caddy, HAProxy, Traefik, Pomerium, and other web-server or reverse-proxy projects
- https://caddyserver.com/docs/quick-starts/reverse-proxy
Supports
- Command-line and Caddyfile proxy setup, client HTTPS, backend HTTPS, trust, and host behavior
- https://www.haproxy.com/documentation/haproxy-configuration-tutorials/
Supports
- HAProxy learning path for configuration, proxying, protocols, health, security, reliability, performance, and monitoring
- https://doc.traefik.io/traefik/v3.2/routing/overview/
Supports
- Traefik entry points, routers, middleware, services, providers, and HTTP or TCP routing
- https://www.pomerium.com/docs
Supports
- Pomerium identity-aware proxy role, request routing, identity checks, context checks, deployment models, and protected services
- https://www.haproxy.com/history
Supports
- HAProxy milestones from 2001 through 2019, including scheduling, health checks, forwarding context, TLS, runtime reconfiguration, HTTP/2, Kubernetes integration, and Prometheus export
- https://nginx.org/
Supports
- NGINX reverse-proxy, content-cache, load-balancer, TCP/UDP proxy, open-source license, and commercial-support positioning
- https://nginx.org/en/enterprise.html
Supports
- NGINX Plus and commercial support availability from F5
- https://docs.haproxy.org/2.4/intro.html
Supports
- HAProxy community licensing under GPLv2 and stable branch lifecycle
- https://www.envoyproxy.io/
Supports
- Envoy as an open-source edge and service proxy with protocol support, traffic policy, dynamic configuration, and observability
- https://traefik.io/traefik/
Supports
- Traefik Proxy as an MIT-licensed reverse proxy, ingress controller, and load balancer
- https://doc.traefik.io/traefik-hub/legal/licensing
Supports
- Commercial subscription licensing for Traefik Hub
- https://caddyserver.com/docs/caddyfile/directives/reverse_proxy
Supports
- Caddy reverse-proxy upstream selection, load balancing, health checks, request manipulation, buffering, forwarding-header behavior, and trust considerations
- https://caddyserver.com/docs/
Supports
- Caddy documentation guidance and its free open-source project status
