proxy_cookie_path仅重写后端Set-Cookie头的Path属性，不处理缓存内容或请求Cookie；需在location块内紧邻proxy_pass配置，配合rewrite、proxy_redirect等确保路径一致性。
proxy_cookie_path 不处理缓存内容中的 Cookie，它只修改后端响应头里 Set-Cookie 的 Path 属性。所谓“缓存内容中携带的 Cookie 路径偏移”，实际是误解——Nginx 缓存（proxy_cache）本身不存储或改写 Cookie；浏览器是否发送 Cookie，取决于当前请求 URL 与 Cookie Path 的匹配关系，而这个 Path 来自后端响应头，必须靠 proxy_cookie_path 在代理响应阶段实时重写。
核心问题：路径不匹配导致 Cookie 不被携带
用户访问 /app/login，后端返回 Set-Cookie: sid=abc; Path=/api，浏览器发现 /api 并非 /app/ 的前缀，直接丢弃该 Cookie。后续所有 /app/ 下的请求都不带 sid，登录态丢失。这不是缓存导致的，而是原始响应路径设置错误，需在 Nginx 响应出口处修正。
proxy_cookie_path 的正确配置方式
指令必须放在 location 块内，且紧邻 proxy_pass 后使用，否则不生效：
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 简单替换：后端返回 Path=/，前端入口是 /app，则写 proxy_cookie_path / /app/;
- 前缀映射：后端接口路径为 /api/v1，代理到 /app/api/v1，用 proxy_cookie_path /api/ /app/api/;
- 正则动态提取：想把 Path=/backend/user → /app/user，可写 proxy_cookie_path ~^/backend/(.*)$ /app/$1;
配合其他指令避免路径错位
仅改 Cookie Path 不够，还需确保整个链路路径一致：
- 用 rewrite ^/app/(.*)$ /api/$1 break; 把客户端请求 /app/xxx 映射成后端能识别的 /api/xxx
- 用 proxy_redirect /api/ /app/; 重写后端返回的 Location 跳转头
- 透传上下文给后端：proxy_set_header X-Forwarded-Prefix /app;，便于其生成正确资源链接
常见误区提醒
proxy_cookie_path 不影响已缓存的响应体内容，也不修改请求头里的 Cookie；它只作用于当前响应的 Set-Cookie 头。如果用了 proxy_cache，首次响应被缓存后，后续命中缓存时仍会返回已被 proxy_cookie_path 重写过的 Set-Cookie —— 因为重写发生在缓存写入之前。所以无需额外处理“缓存中的 Cookie”，重点始终是响应头修正时机和规则准确性。
