Nginx反向代理中后端302重定向导致跨域失败，因浏览器对跳转后请求独立校验CORS；解决方案有三：Nginx拦截重写Location并添加CORS头、后端在302响应中主动返回合规CORS头、前端接收JSON跳转信息自行处理。

nginx跨域实战：解决跨域环境下返回302跳转后的头丢失

当 Nginx 作为反向代理处理跨域请求时，若后端返回 302 重定向，浏览器会直接发起新请求（跳转到 Location 指定的地址），而这个新请求是**全新发起的跨域请求**，不会携带原请求的 Origin、Cookie 等上下文，且响应头中若缺少必要的 CORS 头（如 Access-Control-Allow-Origin），就会被浏览器拦截 —— 表现为“跳转后跨域失败”或“预检通过但跳转后报错”。这不是 Nginx 丢头，而是浏览器对重定向链中每一步都独立执行 CORS 校验所致。

理解 302 在跨域中的真实行为

浏览器对跨域请求的 302 响应有明确限制：

如果原始请求是 CORS 请求（带 Origin 头），且响应含 Access-Control-Allow-Origin，浏览器允许读取 Location 值；
但浏览器不会自动带上原始请求的 CORS 头（如 Origin、Authorization）去访问 Location 地址；
它会以一个“普通跨域请求”发起跳转，此时若跳转目标未正确配置 CORS 响应头，就会触发跨域错误；
即使 Nginx 拦截了 302 并尝试改写 Location 或注入头，也无法改变浏览器对跳转后请求的 CORS 校验逻辑。

方案一：Nginx 层面避免暴露 302 给前端（推荐）

让 Nginx 自行完成重定向，不把 302 透传给浏览器。适用于跳转目标仍在同一代理域下（如都走 /api/ 路由）：

使用 proxy_redirect 重写 Location 响应头，将其映射为前端可接受的相对路径或同源地址；
配合 proxy_intercept_errors on 和自定义 error_page 捕获 302（需开启 proxy_redirect default 或显式规则）；
更稳妥的做法是：用 error_page 301 302 = @handle_redirect; 将 302 拦截，再在 @handle_redirect 中用 return 302 $sent_http_location; 控制跳转，并手动添加 CORS 头。

示例配置片段：

location /api/ {
    proxy_pass http://backend/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
<pre class="brush:php;toolbar:false;"># 拦截后端返回的 302
proxy_intercept_errors on;
error_page 301 302 = @handle_302;

# 添加基础 CORS 头（适用于非跳转场景）
add_header 'Access-Control-Allow-Origin' '$http_origin' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
add_header 'Access-Control-Allow-Headers' 'DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,Range' always;

}

location @handle_302 { internal;

提取原始响应中的 Location

set $redir_url $sent_http_location;
# 清空原始 Location 头，避免干扰
proxy_hide_header Location;
# 手动返回 302，并确保带 CORS 头
add_header 'Access-Control-Allow-Origin' '$http_origin' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
return 302 $redir_url;

}

方案二：后端主动适配跨域跳转

根本解法是让后端识别 CORS 请求，在返回 302 前主动补全 CORS 头（Nginx 无法替后端做语义决策）：

后端检查请求头是否有 Origin，若有，则在 302 响应中必须包含 Access-Control-Allow-Origin（值为具体域名或 *，注意 * 不兼容 credentials）；
若需携带 Cookie，还需返回 Access-Control-Allow-Credentials: true，且 Access-Control-Allow-Origin 不能为 *；
部分框架（如 Spring Boot）需显式配置 UrlBasedCorsConfigurationSource 支持重定向路径；Django 可用中间件拦截 302 响应并注入头。

方案三：前端规避跳转，改用 API 层解析重定向逻辑

不依赖浏览器自动跳转，而是由前端接收 302 响应体（需后端配合返回 JSON 包裹跳转信息），再用 JS 控制跳转：

后端对 CORS 请求，将原本的 302 改为 200 + JSON：{"redirect": true, "url": "/login?next=/admin"}；
前端 fetch 检查 response.data.redirect，再调用 window.location.href = data.url；
此方式完全绕过浏览器 CORS 对重定向的限制，且便于埋点、灰度和错误降级。

核心原则：浏览器对跨域 302 的限制不可绕过，只能选择“不让它发生”（Nginx 拦截重写）、“让它合法发生”（后端透出 CORS 头）或“不用它发生”（前端接管跳转逻辑）。实际选型需结合安全要求（如 SSO 登录跳转是否允许前端拼接）、架构分层规范及排障成本综合判断。