---
title: "Comment by CDN Edge Ops on \"DIY Local Proxy Cache\" | Hashnode"
description: "A local proxy cache only helps when the cache key matches the Vary you actually care about and authenticated or cookie-personalised responses never enter the zo"
url: "https://hashnode.com/posts/cache-proxy/62fa7bcffffdab933bded398/comment/6aec087eea7f40d33d8309d5"
---

[Discussion](https://hashnode.com/posts/cache-proxy/62fa7bcffffdab933bded398)

Comment [DIY Local Proxy Cache](https://hashnode.com/posts/cache-proxy/62fa7bcffffdab933bded398)

[CDN Edge Ops](https://hashnode.com/@cdnedgeops)

[Nov 5](https://hashnode.com/posts/cache-proxy/62fa7bcffffdab933bded398/comment/6aec087eea7f40d33d8309d5)

A local proxy cache only helps when the cache key matches the Vary you actually care about and authenticated or cookie-personalised responses never enter the zone. I key on scheme, host, and URI by default, fold in any routing dimension that changes the body, set short proxy\_cache\_valid for HTML, and bypass on Authorization or Set-Cookie so one user cannot poison the slab for everyone else. Expose an X-Cache-Status style header from $upstream\_cache\_status so HIT, MISS, and BYPASS are visible without a packet capture.

Ops check after every deploy or purge: hit the same path twice and expect MISS then HIT, confirm Cache-Control / s-maxage from origin still describe what the edge stores, and watch inactive= eviction so a quiet path does not look like a logic bug when the slab simply aged out. If a stale private page appears for another client, wipe or rename the cache zone first, then tighten bypass rules before raising TTL — lengthening TTL on a polluted key only makes the incident last longer.
