Nginx反向代理需重写Set-Cookie的Domain和Path属性：用proxy_cookie_domain将后端域名（如b.com）替换为前端域名（a.com），proxy_cookie_path同步调整路径；并确保响应头含Access-Control-Allow-Origin（非*）、Access-Control-Allow-Credentials: true，且Set-Cookie含SameSite=None; Secure，前端请求启用credentials: 'include'。
要让 Nginx 在反向代理中正确转发 Cookie 并解决跨域域名不匹配问题，核心不是“转发请求头里的 Cookie”，而是**重写响应头中的 Set-Cookie 域名和路径**，使浏览器愿意在当前页面域名下保存并发送它。
关键点：proxy_cookie_domain 重写 Domain 属性
后端服务（如 b.com）返回的 Set-Cookie 通常带 Domain=b.com，但前端页面在 a.com 下运行，浏览器会直接丢弃这个 Cookie。Nginx 的 proxy_cookie_domain 就是为这事设计的：
- 指令必须写在
location块内，且放在proxy_pass之后 - 基础写法：
proxy_cookie_domain b.com a.com;—— 把所有Domain=b.com替换为Domain=a.com - 支持正则匹配子域：
proxy_cookie_domain ~\.?b\.com a.com;（兼容b.com和www.b.com） - 如果后端没设 Domain 或设了空值，可用
proxy_cookie_domain "" a.com;强制补上
别漏掉 proxy_cookie_path 修正路径
代理路径和后端原始路径不一致时（比如前端请求 /api/xxx，后端实际处理的是 /xxx），Cookie 的 Path 也得同步调整，否则浏览器认为路径不匹配，不携带该 Cookie：
- 后端设了
Path=/，但你用proxy_pass http://b.com/api/，那就要加：proxy_cookie_path / /api/; - 若后端返回
Path=/backend，而你代理到/api，就写：proxy_cookie_path /backend /api;
配套响应头和 Cookie 属性缺一不可
只改 Domain 和 Path 还不够，浏览器（尤其 Chrome 80+）还会检查以下几项：
-
Access-Control-Allow-Origin必须是具体域名（如https://a.com），不能是* -
Access-Control-Allow-Credentials: true必须显式设置 - 后端 Set-Cookie 必须含
SameSite=None; Secure（HTTPS 环境下才有效） - 前端发起请求时需启用凭据：
fetch(url, { credentials: 'include' })或axios.defaults.withCredentials = true
常见误区提醒
proxy_cookie_domain 只作用于响应头中的 Set-Cookie，不影响请求头里浏览器自动带的 Cookie；它也不处理请求头本身，所以无需额外配置“转发 Cookie 请求头”——浏览器本来就会在同源或满足 SameSite 条件时自动带上。
如果代理后仍拿不到登录态，优先检查响应头里 Set-Cookie 是否真的被重写了 Domain，以及 SameSite 和 Secure 是否齐全。
