核心是让后端Set-Cookie的Domain匹配前端域名，proxy_cookie_domain仅替换响应头中Domain字段；需配合CORS、credentials及Secure/SameSite=None等配置。

核心是让后端 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 自动推导；若 Host 是内网地址（如 10.0.1.5），仍会出问题，也得管
• 后端已设 Domain=.example.com（带前导点），且前端域名都在 example.com 下 → 通常不用配

静态替换：最常用、最稳妥

适用于后端固定的 Domain 值可预知的场景。指令必须放在 location 块内，且在 proxy_pass 之后：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• 把 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
• Cookie 自身需带 Secure（HTTPS 环境下必需）和 SameSite=None（Chrome 80+ 要求）