关键在于用 proxy_cookie_path 严格匹配 Cookie Path 与用户访问路径，再通过重写 Set-Cookie 头添加 HttpOnly、Secure、SameSite 和 proxy_cookie_domain 修正 Domain，确保 Session 正确传递与安全防护。
关键不在“加属性”，而在于让 Cookie 的 Path 与用户实际访问路径严格匹配，否则浏览器直接丢弃，Session 就断了。proxy_cookie_path 是修复路径错位的核心指令，安全加固得建立在这个基础之上。
先确保 Cookie 路径能正确送达
后端应用（比如 Java 应用）生成 Set-Cookie 时，通常按自身部署路径设 Path，例如部署在 /project，就设 Path=/project；但 Nginx 把它代理到 /app，用户地址栏显示的是 /app/xxx，而浏览器只把 Path=/app 的 Cookie 发回去——原来的 /project Cookie 就被无视了。
这时候必须用 proxy_cookie_path 做路径映射：
- 如果后端返回
Set-Cookie: JSESSIONID=abc; Path=/project，而你代理的 location 是/app，就配：proxy_cookie_path /project /app; - 如果后端返回的是
Path=/（常见于proxy_pass http://backend/这种带尾斜杠的写法），但你要代理到/admin，就配：proxy_cookie_path / /admin; - 务必把
proxy_cookie_path放在location块里，且紧挨着proxy_pass，顺序错或位置错都不生效
再叠加 HttpOnly 和 Secure 标志
光路径对还不行，还得防 XSS 和明文传输。Nginx 不能修改已有 Cookie 的属性，但可以**重写整个 Set-Cookie 响应头**，强制注入安全标志：
- 在 location 块中添加：
proxy_cookie_path / "/; HttpOnly; Secure"; - 注意：末尾的
/表示把所有 Cookie 的 Path 统一设为根路径，后面的字符串是追加的安全属性 - Secure 只在 HTTPS 站点生效；若 Nginx 终止 HTTPS（即前端是 HTTPS，后端是 HTTP），这个配置才安全可靠
- HttpOnly 能阻止 JS 读取 Cookie，大幅降低 XSS 盗取 Session 的风险
必要时补上 SameSite 和 Domain 控制
现代浏览器默认对跨站请求限制宽松的 Cookie，容易被 CSRF 利用。建议补充防御层：
- 统一设置 SameSite=Lax（兼顾兼容性与安全性）：
add_header Set-Cookie "Path=/; HttpOnly; Secure; SameSite=Lax" always; - 如果后端设的 Domain 是内网地址（如
Domain=192.168.1.10），而用户访问的是app.example.com，浏览器会拒收——用proxy_cookie_domain修正：proxy_cookie_domain 192.168.1.10 .example.com;（注意开头的点表示子域通配） - Domain 必须以点开头（如
.example.com）才能被子域名共享，且不能包含端口或协议
验证是否生效的小技巧
别只看配置有没有报错，要实测：
- 用浏览器开发者工具 → Application → Cookies，检查访问页面后，Cookie 的 Path、Domain、Secure、HttpOnly 字段是否符合预期
- 发起一次登录，刷新页面，看 Request Headers 中 Cookie 是否自动带上 JSESSIONID 或类似字段
- 用 curl 模拟请求：
curl -I http://your-domain/app/login，观察响应头中Set-Cookie的完整内容 - 关掉浏览器 HTTPS 强制跳转，用 HTTP 访问试试——Secure 标志会让 Cookie 不发送，这是正常现象，说明它起作用了
