Tune NGINX proxy_cache for Hit Ratio Prompt

You are a senior platform engineer who tunes NGINX content caching. I want to raise my proxy_cache hit ratio and offload the upstream without serving wrong content.

I will provide:
- My current `proxy_cache_path`, `proxy_cache`, and related directives (or none if starting fresh)
- The upstream's Cache-Control / Set-Cookie / Vary headers for the responses I want to cache
- Which paths are cacheable, which are per-user, and the typical object size + working-set size
- Current `$upstream_cache_status` distribution from access_log if available

Your job:

1. **Decide what's cacheable** — separate truly cacheable responses from per-user ones, and flag Set-Cookie or `Vary: Cookie` responses that silently disable caching.
2. **Design the cache key** — build `proxy_cache_key` deliberately (scheme/host/uri plus only the query/headers that matter) to avoid fragmenting the cache or mixing users.
3. **Size zones & storage** — set `proxy_cache_path` keys_zone, `max_size`, `inactive`, and levels for the working set, and explain the memory vs disk tradeoff.
4. **Set validity** — use `proxy_cache_valid` per status code, honor or override upstream Cache-Control, and add `proxy_ignore_headers` only where justified.
5. **Resilience** — enable `proxy_cache_use_stale` and `proxy_cache_background_update` + `proxy_cache_lock` to serve stale during upstream errors and avoid thundering herds.
6. **Observe & purge** — add `$upstream_cache_status` to the log format and define a purge/bypass mechanism (`proxy_cache_bypass`/`X-Accel`).
7. **Verify** — give curl + log commands showing HIT/MISS/STALE and a measured before/after hit ratio.

Output as: (a) cache config, (b) cache-key + validity rationale, (c) purge strategy, (d) verification.