Nginx缓存清理关键在于处理“逻辑过期”与“物理存在”的脱节：proxy_cache_valid决定缓存时长，响应头变更不自动删除旧文件；需结合调低inactive时间、精准purge及X-Cache-Status验证来确保过时内容及时退出。
清理“过时的缓存响应头配置项”本身不是直接操作——Nginx 不会因你改了 Cache-Control 或 Expires 头就自动删掉旧缓存文件。真正需要清理的是**已缓存但不再符合新响应头逻辑的内容**，关键在于区分“逻辑过期”和“物理存在”。
响应头变更后，旧缓存不会自动失效
Nginx 的缓存决策依赖两个独立机制：
-
proxy_cache_valid：覆盖响应头，强制指定哪些状态码缓存多久（如
proxy_cache_valid 200 10m）； -
后端返回的 Cache-Control/Expires：仅在未配置
proxy_cache_valid时起作用，且只影响“是否返回缓存”和“是否触发校验”，不触发删除。
也就是说：你把后端响应头从 max-age=300 改成 max-age=60，Nginx 不会因此删掉磁盘上已存的 5 分钟缓存文件——它只是下次请求来时，发现“逻辑已过期”，可能回源或返回 stale 内容（若配了 proxy_cache_use_stale）。
真正清理过时内容，靠 inactive + 精准 purge 组合
要让“不符合新缓存策略”的内容尽快退出系统，必须主动干预：
-
调低 inactive 时间：比如设为
inactive=15m，确保 15 分钟内没被访问的缓存条目被自动 unlink（物理删除），避免长期滞留； -
对已知变更路径做 purge：比如更新了 /api/v1/config 接口，立刻执行
curl -XPURGE https://example.com/api/v1/config，清除该 key 对应的所有缓存副本； -
避免响应头与 proxy_cache_valid 冲突：不要一边配
proxy_cache_valid 200 1h，一边又让后端返回Cache-Control: max-age=10，Nginx 以proxy_cache_valid为准，但容易造成运维预期错位。
检查与验证是否生效
加一句调试头定位真实行为：
add_header X-Cache-Status $upstream_cache_status always;刷新页面看响应头：
-
X-Cache-Status: HIT→ 缓存命中，内容可能已过时； -
X-Cache-Status: EXPIRED→ 逻辑过期，Nginx 已决定回源（但旧文件仍在磁盘）； -
X-Cache-Status: MISS→ 缓存未命中，可能是刚被 purge 或 inactive 清理掉了。
不推荐的“清理”方式
以下操作看似清缓存，实则风险高或无效：
-
rm -rf /var/cache/nginx/*：破坏共享内存索引一致性，引发回源风暴； - 重启 Nginx：
systemctl restart nginx会清空 keys_zone 内存索引，但磁盘文件还在，重启后首次请求仍可能读到旧文件并误判为 HIT； - 只改响应头不 purge/inactive：旧缓存持续服务，用户看到的仍是过时内容，直到自然淘汰或手动干预。
