Reverse Proxies and API Gateways
The Front Door to Your Infrastructure
A reverse proxy sits in front of your servers and handles requests on their behalf. To the outside world it looks like the server; behind it can be dozens of services. It is one of the most valuable and most underrated components in modern infrastructure.
Forward Proxy vs. Reverse Proxy
The distinction is about who the proxy represents:
- A forward proxy acts on behalf of clients. It hides the client's identity from servers. Corporate egress filters and the residential proxies used in scraping are forward proxies.
- A reverse proxy acts on behalf of servers. It hides the backend's structure from clients. NGINX, HAProxy, Envoy, Traefik, and cloud load balancers are reverse proxies.
What a Reverse Proxy Does
- TLS termination: It holds the certificates and decrypts HTTPS, forwarding plain HTTP (or re-encrypted mTLS) to backends. This centralizes certificate management and offloads crypto work.
- Routing: It maps URL paths and hostnames to different backend services:
/apito the API,/imagesto object storage,/to the web app. - Compression & caching: It gzips responses and caches static assets close to the entrance.
- Rate limiting & WAF: It enforces per-IP request limits and filters malicious requests before they reach application code.
- Observability: It logs every request in one place, providing the canonical access log for the system.
The X-Forwarded Headers
Because the reverse proxy is the only machine the client talks to, backends see the proxy's IP as the client. To preserve the real client information, proxies add headers:
X-Forwarded-For: the original client IP (and the chain of proxies).X-Forwarded-Proto:httporhttps.X-Forwarded-Host: the original Host header.X-Real-IP: a common shortcut for the client IP.
Applications must trust these headers only from known proxies. If an app blindly trusts X-Forwarded-For, any client can spoof its own IP and defeat IP-based rate limiting or logging. This is the classic IP spoofing via header vulnerability.
API Gateways
An API gateway is a reverse proxy specialized for APIs. Beyond routing and TLS, it typically adds:
- Authentication: verifying JWTs, API keys, or OAuth tokens at the edge.
- Rate limiting and quotas: per key, per user, per endpoint.
- Request/response transformation: schema validation, payload size limits, header rewrites.
- Analytics and monetization: usage metering for billing.
- Service discovery: routing to dynamic backend instances.
Products like Kong, AWS API Gateway, and Apigee package these concerns so application teams do not re-implement them.
Service Mesh
At very large scale, the gateway pattern is complemented by a service mesh: a fleet of sidecar proxies (Envoy) attached to every service instance that handles service-to-service authentication (mTLS), retries, circuit breaking, and telemetry. The mesh extends the reverse-proxy idea inward, so east-west traffic between microservices gets the same treatment as north-south traffic from the internet.
Deploying a Reverse Proxy Safely
A reverse proxy is a critical single point of failure, so it must be operated accordingly:
- Health-check the backends and remove dead ones from the pool automatically.
- Configure timeouts explicitly. Default proxy timeouts are often too short for slow endpoints and too long for idle keepalive connections.
- Set header size limits to prevent header-based overflow attacks and unbounded header inflation.
- Preserve client information via
X-Forwarded-*—and make the app trust those headers only from the proxy's IP. - Terminate TLS with modern ciphers and automate certificate renewal (ACME/Let's Encrypt).
- Log at the edge, because the proxy sees every request exactly once and is the best place to build the canonical access log.
NGINX is the most widely deployed reverse proxy, but the pattern is identical in HAProxy, Envoy, Traefik, and cloud-managed load balancers. Once you understand the responsibilities—TLS, routing, policy, and observability—you can operate any of them.