Reverse Proxy vs Forward Proxy

Nginx:

upstream backend_pool {
    least_conn;
    keepalive 32;
    server 10.0.0.1:8080 weight=3;
    server 10.0.0.2:8080 weight=1;
    server 10.0.0.3:8080 backup;
}

server {
    listen 443 ssl http2;
    server_name api.example.com;
    ssl_certificate /etc/ssl/api.crt;
    ssl_certificate_key /etc/ssl/api.key;

    location /api/v1/ {
        proxy_pass http://backend_pool;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

HAProxy:

frontend https_frontend
    bind *:443 ssl crt /etc/ssl/api.pem
    default_backend app_servers

backend app_servers
    balance leastconn
    option httpchk GET /health
    server app1 10.0.0.1:8080 check
    server app2 10.0.0.2:8080 check
    server app3 10.0.0.3:8080 check backup

Acceptable when: Proxy and backends are in the same trusted network (same VPC, same rack), the network is not shared with untrusted workloads, and compliance requirements don’t mandate end-to-end encryption.

Must re-encrypt when:

• PCI-DSS, HIPAA, or similar compliance mandates encryption in transit end-to-end
• The backend network is multi-tenant or shared
• Zero-trust architecture is in place (assume the network is hostile)

In practice, service meshes (Istio, Linkerd) solve this with sidecar-to-sidecar mTLS (mutual TLS, where both client and server present certificates to authenticate each other) — the application never handles TLS itself.

The proxy appends the real client IP to the existing X-Forwarded-For, resulting in X-Forwarded-For: 10.0.0.1, <real-ip>. If the backend naively reads the leftmost IP, the attacker appears to be 10.0.0.1 — bypassing per-IP rate limits or impersonating an internal address.

Fix: Configure the proxy to count hops from the right. If you have exactly one trusted proxy, the rightmost IP is the real client. Or use X-Real-IP which the proxy sets to the direct connection IP (not appendable). Some frameworks (Express trust proxy, Django NUM_PROXIES) support this natively.

Stay with a reverse proxy when you only need: TLS termination, path-based routing, static load balancing, connection pooling, and basic per-IP rate limiting. Nginx/Envoy handle these with minimal overhead.

Promote to an API gateway when you need:

• Per-user authentication and authorization (JWT validation, OAuth token introspection, RBAC per endpoint)
• Per-user/API-key rate limiting with quotas and tiered plans
• Dynamic service discovery (backends register/deregister without config reload)
• Request transformation (protocol translation, JSON reshaping, request aggregation)
• API analytics (per-endpoint metrics, usage tracking, billing)

The cost of a gateway: added latency (5–20ms for auth + transformation), another system to operate, and potential single point of failure if not HA’d properly.

With buffering enabled, the proxy attempts to buffer the entire 500MB request body in memory before forwarding to the backend. This can OOM the proxy or exhaust buffer capacity, especially under concurrent large uploads.

Mitigations:

1. client_max_body_size — reject uploads over a threshold (e.g., 50MB) with 413 Content Too Large
2. Disable buffering for upload endpoints — proxy_request_buffering off in Nginx passes data to the backend as a stream (but loses slow-client protection for that route)
3. Dedicated upload path — route large uploads to a separate endpoint that handles them directly (e.g., pre-signed S3 URLs), bypassing the proxy entirely
4. Disk buffering — some proxies can buffer to disk instead of memory, trading I/O latency for memory safety

When the signing key rotates, the gateway can’t validate tokens signed with the old key if it only knows the new key. In-flight requests with old tokens get 401 Unauthorized — a brief authentication outage.

Design for key rotation:

1. JWKS (JSON Web Key Set) endpoint: The gateway fetches keys from /.well-known/jwks.json. The issuer publishes both old and new keys during the rotation window. The gateway tries all keys in the set until one validates.
2. Cache with TTL: Gateway caches the JWKS with a short TTL (5–10 min). On validation failure, it re-fetches the JWKS before returning 401 — this catches key rotations between cache refreshes.
3. kid (Key ID) header: Each JWT’s header includes a kid that identifies which key signed it. The gateway looks up the specific key by kid from the JWKS, avoiding trial-and-error.
4. Overlap period: The issuer keeps the old key in the JWKS for at least as long as the longest-lived token (e.g., if access tokens expire in 15 min, keep the old key for 15 min after rotation).