反向代理后cookie路径失效是因为浏览器严格匹配path，仅当url路径是cookie path的前缀或完全一致时才发送；需用proxy_cookie_path重写path值，且必须在location块中proxy_pass之后配置。
反向代理后 Cookie 路径失效，本质不是报错，而是浏览器直接忽略 Set-Cookie 中的 Path 值，导致后续请求不携带 Cookie（比如 JSESSIONID、token），登录态丢失、接口反复 401。根本原因是后端返回的 Cookie Path 与用户实际访问路径不匹配。
为什么浏览器会丢掉这个 Cookie
浏览器遵循严格路径匹配规则：只有当前 URL 路径是 Cookie Path 的**前缀或完全一致**时，才发送该 Cookie。
- 用户访问 https://example.com/app/login，地址栏路径是
/app/ - 后端返回
Set-Cookie: auth=abc; Path=/→ 浏览器认为 / 不是 /app/ 的父路径（/ 是根，/app/ 是子），拒绝存储 - 若返回
Path=/api，而用户路径是/app/，两者无包含关系，同样被丢弃 - 正确应为
Path=/app或Path=/（/ 是所有路径的父级）
proxy_cookie_path 怎么改才有效
它只重写 Set-Cookie 响应头里的 Path=xxx 部分，不碰 Domain、HttpOnly 等其他字段。关键在 location 块中紧贴 proxy_pass 使用。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
proxy_cookie_path / /app/;：把后端返回的Path=/改成Path=/app/ -
proxy_cookie_path ~^/backend/(.*)$ /app/$1;：正则匹配，将Path=/backend/v1→Path=/app/v1 -
proxy_cookie_path /api/ /app/api/;：简单字符串替换，适合固定前缀场景 - 如果后端已返回
Path=/app/，但你代理到/，就用proxy_cookie_path /app/ /;
配置位置和常见踩坑点
指令必须放在 location 块内，且在 proxy_pass 之后、其他 proxy_* 指令之前；否则不生效。
- ✅ 正确写法：
location /app/ {<br> proxy_pass http://backend/;<br> proxy_cookie_path / /app/;<br> proxy_set_header Host $host;<br> } - ❌ 错误写法：写在 server 块顶层，或写在 proxy_pass 之前，或写在另一个 location 里
- 注意 proxy_pass 尾部斜杠：
→proxy_pass http://backend/;表示“去前缀转发”，后端收到的是 /login，但常返回 Path=/，需补前缀
→proxy_pass http://backend;表示“带前缀转发”，后端收到 /app/login，可能返回 Path=/app/，此时可不改或微调
配合 proxy_cookie_domain 处理多子域场景
如果代理涉及子域名切换（如从 app.example.com 到 api.example.com），单靠 path 不够，还需统一 Domain：
-
proxy_cookie_domain ~\.(example\.com)$ $1;：把后端设的 Domain=api.example.com → example.com -
proxy_cookie_domain ~\.(.+)$ .example.com;：强制设为 .example.com，支持所有子域共享 Cookie - 注意：Domain 值必须带点开头（如
.example.com），且不能跨主域（example.com 和 other.com 不行）
