proxy_cookie_domain仅修正Cookie的Domain字段，需配合proxy_cookie_path修正Path字段，并协同proxy_redirect、X-Forwarded-Prefix及CORS配置，才能确保反代下Cookie正常生效。
proxy_cookie_domain 本身不处理“路径”，它只修正 Set-Cookie 响应头中的 Domain 属性。所谓“修正静态反代后的路径域名一致性”这个说法存在概念混淆——域名（Domain）和路径（Path）是两个独立字段，需分别处理。真正影响静态资源反代后 Cookie 生效的，是 Domain 和 Path 的双重匹配：浏览器要求当前 URL 的 域名必须匹配 Cookie 的 Domain，且 路径前缀必须匹配 Cookie 的 Path。
所以，准确目标应是：
✅ 让 Cookie 的 Domain 匹配用户访问的前端域名（如 app.example.com 或 .example.com）
✅ 同时让 Cookie 的 Path 匹配用户实际访问的路径前缀（如 /admin/、/shop/）
下面分两部分说明怎么做：
一、用 proxy_cookie_domain 修正域名不一致问题
该指令必须写在 location 块中、proxy_pass 之后，用于重写后端返回的 Domain= 值。
后端返回
Set-Cookie: token=abc; Domain=10.0.1.5; Path=/;，用户访问https://admin.example.com
→ 配置：proxy_cookie_domain 10.0.1.5 .example.com;
（注意开头的.，表示允许所有子域读取）后端返回多个可能的 Domain（如
localhost、backend.local、api.internal），可用正则统一收口：proxy_cookie_domain ~\.(?:localhost|backend\.local|api\.internal)$ .example.com;后端没设 Domain（即响应里只有
Set-Cookie: token=abc; Path=/;），浏览器会按响应头Host推导 Domain；若 Host 是内网地址（如10.0.1.5），仍会失效 → 可强制清空并指定：proxy_cookie_domain "" .example.com;
二、必须同步用 proxy_cookie_path 修正路径不一致问题
静态资源站点（如 Vue/React 构建产物）常被代理到非根路径（如 /app/），而后端或 SSR 框架返回的 Cookie Path 是 / 或 /api/，导致浏览器拒绝发送。
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
后端设
Path=/，但用户访问的是https://example.com/app/dashboard
→ 需让 Cookie 只在/app/下生效：proxy_cookie_path / "/app/";后端设
Path=/api/，代理路径为/app/，希望 Cookie 路径变为/app/api/
→proxy_cookie_path /api/ "/app/api/";若后端路径不固定（有时
/v1/，有时/），可用正则统一映射：proxy_cookie_path ~^/(.*)$ "/app/$1";
（注意：$1可能为空，建议配合if ($1 = "") { ... }或确保后端 Path 不为空）
三、配套不可少的其他配置
光修 Cookie 不够，还需保障重定向、请求头、CORS 等协同：
proxy_redirect：修正后端返回的Location跳转地址
例如后端 302 到/login，用户实际在/app/下 →proxy_redirect /login /app/login;proxy_set_header X-Forwarded-Prefix /app;：让后端能动态生成正确资源链接（尤其对 history 模式前端）CORS 必须开启凭据支持：
后端响应头需含：Access-Control-Allow-Origin: https://example.com（不能是*）Access-Control-Allow-Credentials: true
前端请求需带credentials: 'include'HTTPS 环境下，Cookie 还需
Secure和SameSite=None才能跨域生效（由后端设置，Nginx 不负责加）
不复杂但容易忽略
