主备切换不影响浏览器缓存，关键在于URL稳定性、响应头统一和资源版本一致；需确保静态资源带哈希或版本号、Cache-Control策略一致、HTML禁用长期缓存、主备后端逻辑相同。
主备切换本身不影响浏览器缓存，因为缓存存在客户端本地，与后端是哪台 Nginx 提供服务无关。真正需要关注的是：**如何让浏览器在切换前后拿到一致、正确、可复用的内容**——这取决于 URL 稳定性、响应头策略和资源版本控制，而非 VIP 漂移本身。
确保静态资源 URL 具备强一致性
浏览器按完整 URL（含查询参数）做缓存键。若主备节点返回的 JS/CSS 路径不一致（比如一个带 v=1.2，另一个没带），就会被当成两个资源分别缓存或不缓存。
- 所有静态资源路径必须由构建工具统一注入哈希或版本号，例如：/static/app.a1b2c3.js 或 /static/app.js?v=2.3.1
- 避免在 Nginx 中用 sub_filter 动态替换资源 URL（除非灰度必需），否则易导致同一页面在不同节点返回不同链接，破坏缓存复用
- CDN 回源地址始终指向 Keepalived 的 VIP，不直接指向具体 Nginx IP，保证主备响应内容逻辑一致
响应头策略要统一且合理
主备 Nginx 的配置必须完全一致，尤其涉及缓存控制的 header。差异会导致同一 URL 在不同时间/节点返回不同 Cache-Control，引发浏览器误判。
- 静态资源（.js/.css/.woff2/.png）统一设置：add_header Cache-Control "public, immutable"; —— 告诉浏览器“这个资源永不变”，后续带任何 query 参数都不触发新请求
- HTML 文件禁用长期缓存：add_header Cache-Control "no-cache, must-revalidate"; 或 expires -1; —— 强制每次向服务端发起验证，由 Nginx 决定返回新版还是旧版
- 两台机器均启用 ETag 和 Last-Modified（默认开启），确保协商缓存正常工作，避免重复传输
避免因主备状态差异导致内容错乱
如果主备节点后端指向不同环境（如主连旧服务、备连新服务），即使 URL 相同，返回的 JS 内容也可能不兼容，造成浏览器执行异常——这不是缓存问题，而是发布逻辑缺陷。
- 主备 Nginx 应代理同一套后端服务，或通过相同 upstream 配置 + 一致健康检查，确保对外行为无差别
- 若需灰度迁移，应在 Nginx 层用 map 或 split_clients 控制流量，而非依赖主备角色区分新旧逻辑
- 所有 HTML 中引用的资源路径，应由后端渲染时注入确定版本，或由前端构建时固化，不依赖 Nginx 运行时判断
只要 URL 不变、响应头一致、内容语义相同，浏览器就不会感知主备切换。缓存是否“受影响”，本质是服务端交付是否可信，不是 VIP 漂了就失效。
