平滑重载后缓存索引失效是因旧worker进程索引句柄丢失、新worker无法识别磁盘缓存，导致命中率骤降与反复回源；需排查proxy_cache_path一致性、keys_zone共享内存继承及缓存路径权限。
平滑重载（nginx -s reload）后出现缓存目录索引失效，不是配置没生效的表象，而是代理缓存（proxy_cache）机制在进程切换过程中发生了元数据断层——旧 worker 进程持有的缓存索引句柄丢失，新 worker 进程无法识别已缓存内容，导致“缓存命中率骤降”“反复回源”“部分资源返回 502/504”等现象。排查需聚焦缓存路径一致性、共享内存状态和索引重建逻辑。
确认是否真为缓存索引失效而非其他缓存层级问题
先排除浏览器缓存、CDN缓存或 FastCGI 缓存干扰：
- 用
curl -I -H "Cache-Control: no-cache" http://your-domain/path绕过客户端与中间层缓存，直连 Nginx - 检查响应头中是否有
X-Proxy-Cache: MISS或HIT（需你在配置中显式添加add_header X-Proxy-Cache $upstream_cache_status;） - 对比重载前后
/var/log/nginx/access.log中同一请求的$upstream_cache_status字段变化，连续多次MISS即指向索引失效
检查 proxy_cache_path 配置与实际运行路径是否一致
平滑重载时，若 proxy_cache_path 指令中定义的 levels、keys_zone 名称或路径发生变更（哪怕只是空格或注释位置微调），Nginx 新 worker 进程会初始化全新缓存区，旧缓存文件仍存在磁盘但不再被引用：
- 执行
nginx -T 2>/dev/null | grep proxy_cache_path查看当前生效的完整配置行 - 比对
keys_zone=name:size中的name是否与proxy_cache name;指令完全一致（区分大小写、无多余空格） - 确认
proxy_cache_path /path/to/cache ...的物理路径在重载前后未被修改，且该路径下tmp子目录存在且可写
验证共享内存 zone 是否被正确继承
keys_zone 对应的共享内存区域（用于存储缓存键索引）必须由 master 进程持久维护，并在 reload 时传递给新 worker。若该 zone 初始化失败，新 worker 将无法建立有效索引：
- 查看错误日志：
tail -n 50 /var/log/nginx/error.log | grep -i "cache\|zone"，重点关注could not add new cache zone或shared memory zone "xxx" is unknown - 检查系统 shm 限制：
ipcs -m | grep nginx和cat /proc/sys/kernel/shmmax，确保keys_zone定义的 size 不超限（如设为100m，则shmmax至少为 104857600） - 临时增大限制测试：
echo 209715200 > /proc/sys/kernel/shmmax（重启后失效，仅用于验证）
观察缓存文件结构是否被破坏或孤立
即使索引失效，旧缓存文件通常仍保留在磁盘上。若其目录结构（按 levels=1:2 生成的哈希子目录）被误删、权限变更或挂载点异常，新进程也无法重建索引：
- 进入缓存根目录：
ls -la /path/to/cache，确认tmp目录存在且属主为 nginx 运行用户（如www-data） - 随机选一个缓存文件（如
/path/to/cache/ab/cdef1234567890...），用stat查看其 ctime/mtime，若远早于 reload 时间，说明是旧文件；再用file命令确认是否仍是有效 HTTP 响应体 - 手动触发一次新缓存：
curl -I http://your-domain/some-new-path，检查是否在对应哈希路径下生成了新文件；若没有，说明索引重建流程卡住
不复杂但容易忽略：平滑重载本身不会清空磁盘缓存，但会切断旧索引。真正恢复依赖配置稳定、共享内存可用、路径权限正确这三点闭环。只要其中一环松动，缓存就变成“沉睡的硬盘垃圾”。
