Caching Reverse Proxy

title: "Reverse Proxy Caching — Nginx and Varnish for API Caching" description: "Reverse proxy caching with Nginx or Varnish sits in front of application servers, caching entire HTTP responses and serving them directly to reduce app load." date: 2026-06-28 lastmod: 2026-06-28 weight: 18 tags: [apis, caching] }

Reverse proxy caching places Nginx or Varnish in front of application servers to cache and serve HTTP responses directly, reducing application server load by over 90%.

What You'll Learn

• Nginx proxy cache configuration
• Varnish Cache Configuration Language
• Cache purging and bypass

Why It Matters

Reverse proxy caching offloads requests from application servers. A single Nginx instance can handle 10,000+ cached requests per second.

Code Examples

# Nginx proxy cache configuration
http {
    proxy_cache_path /var/cache/nginx levels=1:2
                     keys_zone=api_cache:10m
                     max_size=1g
                     inactive=60m
                     use_temp_path=off;

    server {
        listen 80;
        server_name api.example.com;

        location /api/ {
            proxy_cache api_cache;
            proxy_cache_key "$scheme$request_method$host$request_uri";
            proxy_cache_valid 200 302 5m;
            proxy_cache_valid 404 1m;
            proxy_cache_use_stale error timeout updating;

            # Bypass cache for authenticated requests
            proxy_no_cache $http_authorization;
            proxy_cache_bypass $http_authorization;

            proxy_pass http://app_server:3000;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        # Cache purging endpoint
        location ~ /purge(/.*) {
            allow 127.0.0.1;
            deny all;
            proxy_cache_purge api_cache "$scheme$request_method$host$1";
        }
    }
}

# Varnish Cache Configuration Language (VCL)
vcl 4.0;

backend default {
    .host = "app_server";
    .port = "3000";
}

sub vcl_recv {
    # Bypass cache for POST requests
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }

    # Bypass for authenticated requests
    if (req.http.Authorization) {
        return (pass);
    }

    # Remove cookies for cacheable content
    unset req.http.Cookie;
}

sub vcl_backend_response {
    # Cache 200 and 302 responses for 5 minutes
    if (beresp.status == 200 || beresp.status == 302) {
        set beresp.ttl = 5m;
    }

    # Never cache 5xx errors
    if (beresp.status >= 500) {
        set beresp.ttl = 0s;
    }
}

Common Mistakes

1. No Cache Key Customization

Default cache keys may ignore important factors like language or version.

2. Caching POST Requests

POST requests are not cacheable by default. Only cache GET/HEAD.

3. Not Setting Cache Bypass Rules

Authenticated or user-specific requests must bypass the proxy cache.

4. No Cache Purging Mechanism

Without purge, stale cached responses persist until TTL expires.

5. Inactive Timeout Too Short

Remove cached items too aggressively, reducing cache hit ratio.

Practice Questions

1. What is the difference between proxy cache and app-level cache?
2. How does Nginx determine cache keys?
3. Why bypass cache for authenticated requests?
4. What is cache purging?
5. How does proxy cache reduce app server load?

Answers:

1. Proxy cache stores HTTP responses; app cache stores application data.
2. Using proxy_cache_key directive combining request attributes.
3. Authenticated responses contain user-specific data.
4. Removing specific cached entries before TTL expires.
5. Cached responses never reach the app server, freeing resources.

Challenge: Set up Nginx as a reverse proxy cache for your API. Configure cache bypass for authenticated routes and a purge endpoint.

FAQ