浏览器缓存302重定向是常见原因，需检查响应头中cache-control或expires字段；应显式配置add_header cache-control "private, max-age=0"禁用缓存，并确认nginx配置已生效且未被覆盖。
遇到 Nginx 配置了临时重定向（如 return 302 或 rewrite ... redirect）后，客户端浏览器仍跳转到旧地址，大概率不是 Nginx 没生效，而是浏览器把重定向响应本身缓存了——尤其当响应头中意外带了 Cache-Control: public, max-age=3600 或 Expires 时，302 也会被缓存。
确认是否是浏览器缓存了重定向响应
302 重定向本身可被缓存，这是 HTTP 协议允许的行为。关键看响应头：
- 用
curl -I http://your-domain.com/old-path查看原始响应头，重点检查是否有Cache-Control、Expires或Age - 若返回状态码是
302且含Cache-Control: max-age=3600，说明浏览器很可能复用了这个跳转，根本没再请求 Nginx - 换无痕窗口访问，或清空当前域名所有缓存（Chrome 开发者工具 → Application → Clear storage → “Clear site data”），再测试
检查 Nginx 是否主动禁止缓存重定向
临时重定向理应不被缓存，需在对应 location 中显式声明：
Comet AI 浏览器
下载
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
- 添加
add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate"; - 或更简洁地写
add_header Cache-Control "private, max-age=0"; - 避免使用
expires -1;（它只对 200 响应有效，对 302 无效） - 确保该配置位于实际触发重定向的 location 块内，而非父块或 http 全局块
排查 Nginx 配置是否真正生效
重定向指令可能被其他规则覆盖或未加载：
- 运行
nginx -t确认语法无误，再执行nginx -s reload（不是 restart） - 检查是否有多个 server 或 location 匹配，导致重定向规则未命中（可用
nginx -T输出全部生效配置，搜索你的路径） - 确认 rewrite 或 return 指令前没有
break、last误用，或被 if 块逻辑绕过 - 查看 access.log，确认请求确实到达了你配置重定向的 location，并返回了 302
排除其他缓存层干扰
重定向响应可能被中间层缓存，不止浏览器：
- CDN（如 Cloudflare）默认会缓存 301/302，需在 CDN 后台关闭“遵循浏览器缓存头”或手动设置该路径缓存等级为“绕过”
- 如果用了 Nginx 的
proxy_cache，且该重定向由 proxy_pass 后端返回，需确认proxy_cache_bypass和proxy_no_cache已设为始终跳过缓存 - 公司代理或 ISP 缓存也可能介入，可通过不同网络（如手机热点）复现验证
