proxy_cookie_domain用于重写Set-Cookie的Domain属性以解决域名不匹配导致Cookie被丢弃的问题，仅修改Domain字段，需配合CORS凭据配置才能生效。
直接用 proxy_cookie_domain 重写后端响应中 Set-Cookie 的 Domain 属性，就能让浏览器在前端访问域名下合法存储和发送 Cookie。它不碰请求头里的 Cookie，也不改 Path 或 Secure 字段，只专注解决“域名不匹配导致 Cookie 被丢弃”这个关键问题。
什么情况下必须启用
不是所有反代场景都需要它。只有当后端返回的 Set-Cookie 明确设置了 Domain=xxx，且该值与用户当前访问的前端域名不兼容时，才必须配置：
- 后端返回
Set-Cookie: sid=123; Domain=api.example.com，而用户打开的是shop.example.com→ 浏览器拒绝存，需替换 - 后端返回
Set-Cookie: sid=123（没设Domain）→ 浏览器按响应头Host自动推导，若Host是内网地址（如10.0.1.5），仍会失效，也需干预 - 后端压根没返回
Set-Cookie，或已设Domain=.example.com→ 通常无需配置
静态替换：适用于固定后端域名
当后端 Domain 值稳定、可预知时，用字面量匹配最简洁。指令必须放在 location 块内，且在 proxy_pass 之后：
- 把
Domain=backend.local改成Domain=.example.com：proxy_cookie_domain backend.local .example.com; - 把
Domain=192.168.1.20改为通配子域格式：proxy_cookie_domain 192.168.1.20 .example.com; - 注意点号不能省：
.example.com表示允许所有子域读取；example.com（无点）则只精确匹配该域名
正则匹配：应对动态或模糊域名
当后端可能返回多种格式（如 Domain=api.example.com、Domain=.api.example.com、甚至 Domain=localhost），静态替换容易漏掉。用正则可一次覆盖：
- 统一收口到主域：
proxy_cookie_domain ~\.?api\.example\.com .example.com; - 清空原有
Domain并强制设为指定值（适合后端未设或设错）：proxy_cookie_domain "" .example.com; - 匹配带端口的 upstream：
proxy_cookie_domain ~\b192\.168\.1\.20:8080\b .example.com;
配套配置缺一不可
proxy_cookie_domain 单独启用无法让 Cookie 正常跨域工作，还需同步满足以下条件：
- 后端响应头含
Access-Control-Allow-Origin: https://example.com（不能是*） - 后端响应头含
Access-Control-Allow-Credentials: true - 前端请求开启凭据：
fetch(url, { credentials: 'include' })或xhr.withCredentials = true
