主备切换时proxy_cache不共享，需验证误清、重复穿透及客户端中断；须确保keys_zone、proxy_cache_key等配置一致，并通过X-Cache-From头、短缓存时间、时间戳请求追踪行为链路。
测试 proxy_cache 在主备节点切换时的表现，关键不是看“缓存还在不在”，而是验证“切换过程中缓存是否被误清、请求是否重复穿透、客户端是否感知中断”。因为 Nginx 的 proxy_cache 是本地磁盘或内存级的，**不共享、不复制、不同步**——主备节点各自的 cache 完全独立。所以切换本身不会迁移缓存，但会影响缓存命中路径和一致性体验。
确认 cache 配置在主备节点完全一致
这是前提。若两台 Nginx 的 cache 路径、keys_zone 名称、inactive 时间、use_temp_path 设置不同，会导致行为不可比：
- 检查 proxy_cache_path 的 keys_zone 名称（如
my_cache）必须相同，否则即使路径一样，Nginx 也视为不同缓存区 - 确保 proxy_cache_key 定义一致（尤其注意是否包含 $host、$scheme、请求头等），否则同一 URL 在主备可能生成不同 key，命中率天然不一致
- cache 路径（如
/var/cache/nginx/my_cache）无需相同，但建议权限、磁盘类型、inode 限制保持一致，避免因写入失败导致静默降级
设计可区分主备响应的缓存测试用例
单纯 curl 一个 URL 看返回，无法判断是主节点缓存响应，还是备节点重建缓存后响应。需注入可追踪标识：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 在每台 Nginx 的 server 块中添加唯一响应头：
add_header X-Cache-From "nginx-master-01";（备机改为nginx-backup-02） - 配合 proxy_cache_valid 对测试接口（如
/api/status）设置短缓存时间（如20s），便于观察冷热状态 - 用带时间戳的请求触发缓存，例如：
curl -sI "http://vip.example.com/api/status?t=$(date +%s)"，避免浏览器或代理缓存干扰
模拟切换并观测 cache 行为链路
真实切换（如停主 Nginx 或 kill keepalived）时，重点抓三个阶段的行为：
-
切换前：连续请求，确认
X-Cache-From固定为主节点，且X-Cache: HIT持续出现 -
切换瞬间（VIP 漂移期间）：会出现 1–2 次连接超时或
502 Bad Gateway（取决于健康检查间隔与 TCP 重传），此时新请求全部打到备机，触发全新 cache 构建 -
切换后：请求应稳定返回备机标识，且
X-Cache: MISS出现几次后转为HIT—— 若长期MISS，说明备机 cache 配置未生效或 key 不匹配
验证缓存穿透与业务影响
主备切换不应导致后端服务被重复压垮。可通过以下方式验证：
- 在后端服务日志中统计同一请求（如
GET /api/data）在切换前后 30 秒内的访问频次：理想情况是主节点缓存失效前已覆盖大部分请求，备节点重建缓存期间仅少量穿透（≤ 原并发量的 10%） - 开启 proxy_cache_lock on;，防止高并发下多个请求同时回源重建缓存；搭配 proxy_cache_lock_age 5s 控制锁等待窗口
- 若业务允许，对高频只读接口启用 proxy_cache_use_stale updating;，让旧缓存继续服务，同时后台异步刷新，进一步平滑切换抖动
