核心是让后端set-cookie的domain匹配前端域名，proxy_cookie_domain仅替换响应头中domain字段；需配合cors凭据配置及secure/samesite属性才能使跨域cookie生效。
核心是让后端 Set-Cookie 中的 Domain 值匹配用户实际访问的前端域名，浏览器才肯存、敢发。proxy_cookie_domain 不改请求头，也不动 Cookie 内容，只精准替换响应头里那个“不听话”的 Domain 字段。
先确认真需要它
不是所有代理都要配。只有当后端响应中明确带了 Domain=xxx，且这个 xxx 和你前端域名对不上时，才必须干预：
- 后端返回
Set-Cookie: token=abc; Domain=192.168.1.100;，用户却在app.example.com打开页面 → 浏览器直接丢弃 - 后端返回
Set-Cookie: sid=123; Domain=backend.local;，而 Nginx 入口是admin.test.com→ 同样失效 - 后端压根没写 Domain（比如只返回
Set-Cookie: sid=123;），但响应头 Host 是内网地址（如10.0.1.5），浏览器会按 Host 自动推导 Domain → 仍会出问题，也得管 - 后端已设
Domain=.example.com（带前导点），且前端域名都在example.com下 → 通常不用配
静态替换：最常用、最稳妥
适用于后端固定的 Domain 值可预知的场景。指令必须放在 location 块内，且在 proxy_pass 之后：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 把
Domain=192.168.1.100改成通配子域格式：proxy_cookie_domain 192.168.1.100 .example.com; - 把
Domain=backend.local替换为公开主域：proxy_cookie_domain backend.local .example.com; - 注意：目标域名前的点不能省 ——
.example.com表示允许www.example.com、api.example.com等所有子域读取；写成example.com（无点）则只精确匹配该一级域名
正则匹配：应对模糊或动态情况
当后端可能返回多种 Domain 格式（如 api.example.com、.api.example.com、localhost:8080），静态替换容易漏，这时用正则一次覆盖：
- 统一收口到主域：
proxy_cookie_domain ~\.?api\.example\.com .example.com; - 清空原有 Domain 并强制设值（适合后端没设或设错）：
proxy_cookie_domain "" .example.com; - 匹配带端口的内网地址：
proxy_cookie_domain ~\b192\.168\.1\.20:8080\b .example.com;
配套配置缺一不可
只配 proxy_cookie_domain 不足以让跨域 Cookie 正常工作，还必须同步满足：
- 后端响应头含
Access-Control-Allow-Origin: https://app.example.com（不能是*） - 后端响应头含
Access-Control-Allow-Credentials: true - 前端请求开启凭据：
fetch(url, { credentials: 'include' })或xhr.withCredentials = true - 若涉及 HTTPS 前端，后端 Cookie 还需加
Secure和SameSite=None属性
