Reverse Proxy
A reverse proxy is a middleman between you and a website’s actual servers. When you visit a site, your request goes to the reverse proxy first. The proxy decides which backend server should handle it, fetches the response, and sends it back to you. You never interact with the real servers directly. This adds security (attackers cannot reach the backend), flexibility (you can swap servers without users noticing), and performance (the proxy can cache responses).
A reverse proxy is a server that accepts client requests and forwards them to one or more backend (origin) servers, returning the backend’s response to the client as if the proxy itself generated it. This is the inverse of a forward proxy (which acts on behalf of clients to reach external servers).
Core functions:
- TLS termination: decrypt HTTPS at the proxy, forward plaintext HTTP to backends on a trusted internal network
- Request routing: direct traffic to different backends based on URL path, hostname, headers, or cookies
- Caching: store frequently requested responses (static assets, API results) to reduce backend load
- Compression: gzip/brotli compress responses before sending to clients
- Rate limiting: throttle requests per IP or API key
- Header manipulation: add, remove, or modify request/response headers (X-Forwarded-For, CORS, security headers)
- SSL offloading: handle certificate management centrally rather than on each backend
Reverse proxy vs. load balancer: a load balancer distributes traffic across multiple backends for scalability. A reverse proxy may do the same, but also handles single-backend scenarios for security, caching, and TLS. In practice, most reverse proxies also load balance, and most load balancers also reverse proxy. The distinction is more about primary intent.
Common software: Nginx, Caddy, Traefik, HAProxy, Envoy, Apache (mod_proxy).
Security benefits:
- Backend servers are never directly exposed to the internet
- DDoS mitigation at the proxy layer
- Centralized WAF and access control
- IP address masking of backend infrastructure
Caddy reverse proxy (auto-HTTPS)
# Caddyfile — automatic TLS via Let's Encrypt
app.bytesnation.com {
reverse_proxy 10.0.1.10:3000 10.0.1.11:3000 {
lb_policy least_conn
health_uri /health
health_interval 10s
}
encode gzip zstd
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
}
}
# Nginx equivalent
server {
listen 443 ssl;
server_name app.bytesnation.com;
location / {
proxy_pass http://10.0.1.10:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /static/ {
proxy_pass http://10.0.1.10:3000;
proxy_cache_valid 200 1d;
add_header X-Cache-Status $upstream_cache_status;
}
} Reverse proxies are everywhere. Cloudflare’s entire product is a globally distributed reverse proxy. Every Kubernetes cluster runs a reverse proxy as its Ingress controller. In homelabs, Nginx Proxy Manager or Traefik centralizes access to all self-hosted services (Proxmox, Grafana, Home Assistant, Portainer) behind a single domain with automatic TLS certificates. Caddy has gained popularity for its zero-config automatic HTTPS. The reverse proxy pattern also enables blue-green deployments: switch the proxy’s backend from the old version to the new version with zero downtime. When troubleshooting “502 Bad Gateway” errors, the reverse proxy is usually the first place to check, as it means the proxy could not reach or get a valid response from the backend.