proxy_cookie_domain未生效是因为它只改写显式声明Domain的Set-Cookie头，且要求格式标准；对无Domain属性的Cookie完全不处理。
Proxy-Cookie-Domain 为什么没生效？
直接加 proxy_cookie_domain 却发现浏览器里 Cookie 的 Domain 还是后端返回的原始值，大概率是因为 Nginx 默认只改写 Set-Cookie 头中显式声明了 Domain= 的条目，且要求后端响应头必须是标准格式（比如不能有多余空格、大小写混用或缺失分号）。更关键的是：它不处理没有 Domain 属性的 Cookie —— 这类 Cookie 会被浏览器按当前响应域名自动设域，而 Nginx 完全不干预。
常见错误现象包括：Set-Cookie: sessionid=abc; Path=/; HttpOnly 这种没 Domain 的，proxy_cookie_domain 直接跳过；或者后端写了 Domain=backend.example.com，但 Nginx 配置写成 proxy_cookie_domain backend.example.com $host; 却漏了末尾分号或用了错误的正则语法。
正确配置 proxy_cookie_domain 的写法和参数含义
核心规则：Nginx 的 proxy_cookie_domain 是模式匹配 + 替换，不是简单字符串替换。它支持字面量和正则两种模式，但正则必须以 ~ 开头，且整个匹配值必须完整对应原始 Domain=xxx 中的 xxx 部分。
- 字面量替换（最常用）：
proxy_cookie_domain backend.example.com example.com;→ 把Domain=backend.example.com改成Domain=example.com - 正则替换（需转义点号）：
proxy_cookie_domain ~^backend\.example\.com$ example.com;→ 精确匹配，避免误替backend.example.com.cn - 清空 Domain 属性（让浏览器按请求 Host 自动设域）：
proxy_cookie_domain ~. "";或更安全地proxy_cookie_domain ~^(.+)$ ""; - 如果后端压根没写 Domain，想强制加上，
proxy_cookie_domain无能为力 —— 得用proxy_cookie_path配合add_header Set-Cookie手动重写整条头（见下一条）
后端没设 Domain 时怎么补上？
当后端返回的 Set-Cookie 不含 Domain（如 sessionid=abc; Path=/; HttpOnly），Nginx 不会主动添加。此时得拦截响应头，用 add_header 覆盖或追加。但注意：add_header 默认不继承上级作用域，且会覆盖同名头 —— 必须配合 always 参数才能对非 2xx 响应生效，还要防重复添加。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
实操建议：
- 用
map提前提取原始Set-Cookie值（需要http块启用underscores_in_headers on;并确保后端不传下划线字段） - 更稳妥的做法是关闭后端的 Cookie 域控制，在 Nginx 层统一注入：
add_header Set-Cookie "sessionid=$cookie_sessionid; Domain=example.com; Path=/; HttpOnly; Secure" always; - 但这样会丢失后端设置的其他属性（如
Max-Age、SameSite），所以实际中建议后端规范输出Domain，Nginx 只做转换
调试和验证的关键点
光看 Nginx 配置是否“看起来对”没用，必须逐层验证：
- 用
curl -I http://your-proxy/检查响应头里Set-Cookie是否已变，注意区分大小写和空格 - 在浏览器开发者工具的 Application → Cookies 里看最终存下来的 Domain 值，不是响应头里的原始值
- 如果用了 HTTPS，确认
Secure属性存在，否则浏览器拒绝存储；同时检查SameSite是否为Lax或Strict导致跨域请求不带 Cookie -
proxy_cookie_domain只影响从后端收到的响应，不影响 Nginx 自己生成的 Cookie（如 auth_request 模块产生的）
最容易被忽略的是：多个 Set-Cookie 头时，Nginx 会逐条匹配处理，但一旦某条匹配失败（比如正则写错），那条就原样透传 —— 所以务必用 curl -v 看原始响应流，别只信浏览器界面。
