Explain what each parameter does in the nginx directive `proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:10m max_size=10g inactive=60m use_temp_path=off;`, and how `inactive` differs from `proxy_cache_valid`.

## Parameter by parameter **The path.** Cached bodies are ordinary files under this directory. The filename is the MD5 hash of the cache key, so a given key always maps to the same file. **`levels=1:2`.** Without it, every file lands in one directory. Filesystems handle millions of entries in a single directory badly, and so do the tools you will eventually use to inspect it. `levels=1:2` builds a path from the last characters of the hash — one character for the first directory, two for the second — producing something like `/var/cache/nginx/c/29/b7f54b2df7773722d382f4809d65029c`. Up to three levels are allowed, each `1` or `2` characters. The value has no effect on hit ratio or on the key; it is purely a layout decision, and `1:2` is the conventional choice. **`keys_zone=api:10m`.** Two things at once: it *names* the cache (the name is what `proxy_cache api;` refers to) and it sizes the shared-memory zone holding one small record per cached entry — the key hash, size, timestamps, use count. The documented density is about eight thousand keys per megabyte, so 10m ≈ 80,000 entries. This zone is the real ceiling on how many objects you can cache. When it fills, nginx force-evicts the least recently used entries to make room, which is why a cache can plateau at a poor hit ratio while the disk sits far below `max_size`. Sizing rule: estimate the object count first, then divide by 8,000. **`max_size=10g`.** The disk budget. It is enforced by the cache manager process, which wakes periodically and deletes least-recently-used entries until usage is back under the limit — so it is a bound that may be briefly overshot between passes, not an instantaneous hard stop. Omit it and the cache grows until the filesystem does. There is also `min_free`, which lets you express the limit as free space to leave rather than space to use. **`inactive=60m`.** The eviction clock, default ten minutes. An entry that nobody requests within the window is deleted by the cache manager even if its content is still perfectly fresh. Each request to an entry restarts its clock. **`use_temp_path=off`.** While receiving an upstream response, nginx writes it to a temporary file first, then moves it into place. By default the temporary directory is `proxy_temp_path`, which frequently lives on a different filesystem from the cache — and a move across filesystems is a full copy. Setting `off` writes the temporary file inside the cache directory so the commit is a cheap rename. ## inactive versus proxy_cache_valid — the confusion worth clearing They answer different questions: - `proxy_cache_valid 200 10m;` says: *for ten minutes, a stored 200 may be handed to a client as a HIT.* After that, the entry is stale. It is still on disk; the next request logs `EXPIRED`, and nginx refetches (or revalidates, if `proxy_cache_revalidate on` and the upstream sent a validator). - `inactive=60m` says: *if nobody asks for this entry for an hour, delete it.* So a popular URL cached for ten minutes lives on disk indefinitely, being refreshed every ten minutes, because traffic keeps resetting the inactive clock. An unpopular URL cached for a day disappears after an hour of silence, because nobody kept it alive. That combination is exactly what you want: freshness governs correctness, inactivity governs footprint. ```nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:10m max_size=10g inactive=60m use_temp_path=off; location /api/ { proxy_pass http://backend; proxy_cache api; proxy_cache_valid 200 10m; # freshness } ``` A classic misconfiguration is `inactive` shorter than `proxy_cache_valid` on a low-traffic endpoint: you declare a one-hour lifetime, but with the default ten-minute inactivity every entry is deleted long before it expires, and the hit ratio never rises. If you want long-lived entries on quiet URLs, `inactive` must exceed the validity you intend. ## Sizing in practice Start from the working set. If roughly 200,000 distinct URLs are worth caching and the median body is 30 KB, you need a zone of at least 25m and roughly 6 GB of disk. Then confirm with observation: a hit ratio that stops improving while disk stays flat below `max_size` points at the keys zone; disk pinned at `max_size` with steady evictions points at disk; entries vanishing between requests on a quiet endpoint points at `inactive`.