nginx平滑重载不主动清空proxy_cache，但修改proxy_cache_valid等指令会导致新旧worker缓存策略并行；真正丢失缓存是因keys_zone改名、删除proxy_cache指令或缓存目录权限/路径变更所致。
Nginx 平滑重载本身不会清空或失效已加载的缓存（如 proxy_cache），但若重载过程中修改了缓存相关配置（如 proxy_cache_valid、proxy_cache_bypass、proxy_cache_key 或 proxy_cache 引用的 zone 名），新 worker 进程会按新规则处理后续请求，而旧 worker 仍按旧规则服务未完成连接——这会造成缓存行为不一致，看似“缓存失效”，实为新旧配置并行导致的策略割裂。
确保缓存行为连续的关键配置项
以下指令在 reload 后立即生效，且不影响已有缓存内容，但会改变新请求的缓存决策逻辑：
-
proxy_cache_valid：新 worker 对新请求应用新过期时间；已缓存条目仍按原 TTL 倒计时，到期后按新规则重新缓存 -
proxy_cache_bypass和proxy_no_cache：reload 后新请求是否跳过缓存，由新值决定；旧请求不受影响 -
proxy_cache_key：仅影响新请求生成的 key；旧 key 对应的缓存条目仍可命中，但后续同 URI 请求若 key 变化，则生成新缓存项 -
proxy_cache_use_stale和proxy_cache_background_update：reload 后新 worker 立即启用新容错策略，旧 worker 继续执行原有 stale/refresh 行为
真正会导致缓存“丢失”的操作
这些不是 reload 本身引起，而是配置变更方式不当所致：
- 修改
proxy_cache_path的keys_zone名称（如从my_cache改为my_cache_v2）：新 worker 使用全新缓存区，旧缓存彻底不可见 - 删除或注释掉
proxy_cache my_cache;指令：新请求不再进入缓存流程，等效于全局 bypass - 更改
proxy_cache_path的磁盘路径或权限，导致新 worker 无法读写缓存目录：日志报open() "/var/cache/nginx/..." failed (13: Permission denied)，所有新缓存失败
reload 前必须做的三件事
避免缓存策略意外中断或分裂：
- 运行
nginx -t，重点检查：proxy_cache引用的 zone 是否在http块中正确定义；proxy_cache_key是否含易变字段（如未过滤的$args）；proxy_cache_valid是否覆盖了目标状态码（如漏写404） - 确认
proxy_cache_path所在目录对 Nginx worker 用户（如www-data）有读写权限，且磁盘空间充足 - 若调整了
proxy_cache_key，评估是否需主动 purge 旧 key：启用ngx_cache_purge模块后，可通过curl -X PURGE http://host/path清理，或临时加proxy_cache_purge on;配合条件匹配
验证缓存是否平稳过渡
reload 完成后，不要只看进程是否双活，要观察真实行为：
- 用
curl -I多次请求同一资源，检查响应头中X-Cache-Status（需提前配置add_header X-Cache-Status $upstream_cache_status;）：新请求应逐步出现HIT，而非持续MISS或BYPASS - 对比新旧 worker 的缓存命中率：通过
nginx_stub_status或日志统计$upstream_cache_status字段分布，确认无大面积EXPIRED或STALE突增 - 检查错误日志：关注
cache manager process ... exited或cache loader process ... exited是否异常退出，这类退出可能触发缓存区重建
