必须用 proxy_cookie_path 在 Nginx 层修正 Cookie Path 值，因后端设 Path=/api/v1/ 而用户访问 /app/ 时浏览器拒绝发送该 Cookie；需根据前后端路径关系配置字符串替换或正则替换，并配合 proxy_redirect、rewrite 等确保路径一致。
当后端应用部署在非根路径（如 /api/v1/）下，而用户实际通过 Nginx 访问的是前端上下文路径（如 /app/ 或 /）时，它返回的 Set-Cookie: token=xxx; Path=/api/v1/ 会被浏览器拒绝携带——因为浏览器只在请求 URL 路径以 Cookie 的 Path 为前缀时才发送该 Cookie。此时必须用 proxy_cookie_path 在 Nginx 层修正这个路径值。
明确前后端路径关系再配置
先确认两个关键路径：
- 后端生成 Cookie 时写的原始
Path值（比如/api/v1/、/或/project） - 用户浏览器地址栏中实际访问的路径前缀（比如
/app/、/或/cms/）
二者不一致就是问题根源。例如后端设 Path=/api/v1/，但用户访问 https://site.com/app/login，浏览器不会把该 Cookie 发给任何 /app/ 下的请求。
基础字符串替换：最常用也最稳妥
适用于后端路径固定、替换目标明确的场景。语法是 proxy_cookie_path 源路径 目标路径;，写在 location 块内、proxy_pass 之后。
- 后端设
Path=/api/v1/，前端暴露在/app/→ 写：proxy_cookie_path /api/v1/ /app/; - 后端设
Path=/project/，代理路径是/proxy_path→ 写：proxy_cookie_path /project/ /proxy_path/; - 后端设
Path=/，但你想限定只在/admin下生效 → 写：proxy_cookie_path / /admin/;
正则匹配替换：应对动态或复杂路径
当后端路径含变量、版本号或需提取片段时，用正则更灵活。注意开头加 ~（区分大小写）或 ~*（忽略大小写）。
- 把所有
/backend/v2/xxx形式的路径转成/api/xxx：proxy_cookie_path ~^/backend/v2/(.*)$ /api/$1; - 把
/user/abc123中的用户名提取出来，变成/u/abc123：proxy_cookie_path ~^/user/([^/]+) /u/$1; - 统一将带版本前缀的路径（如
/v1/、/v2/）去掉：proxy_cookie_path ~^/v\d+/ /;
配合其他指令确保整体路径一致
只改 Cookie 路径不够，后端返回的跳转地址（Location）、资源链接、API 前缀等也得对齐，否则仍会出错。
- 用
proxy_redirect /api/v1/ /app/;重写响应头中的跳转路径 - 用
rewrite ^/app/(.*)$ /api/v1/$1 break;把客户端请求映射到后端真实路径 - 透传上下文给后端：
proxy_set_header X-Forwarded-Prefix /app;，方便它生成正确链接
这些指令都应和 proxy_cookie_path 放在同一 location 块中，顺序建议：先 proxy_pass，紧接 proxy_cookie_path，再其他 proxy_* 指令。
