Nginx 作为 HTTPS 反向代理时，必须通过 proxy_cookie_path 精准重写后端 Set-Cookie 的 Path 并追加 HttpOnly、Secure、SameSite 属性，确保路径对齐且指令置于 location 块内 proxy_pass 后；兜底可用 add_header（慎防冲突），高版本可选 proxy_cookie_flags 实现精细化控制。
在 Nginx 作为 HTTPS 反向代理时，安全 Cookie（HttpOnly、Secure、SameSite）不能靠后端“默认生成”来保障，必须由 Nginx 主动拦截并重写响应头中的 Set-Cookie。核心不是添加新头，而是精准改写已有 Cookie 字段——尤其要注意路径对齐和指令位置。
先对齐 Cookie Path，否则注入无效
后端应用（如 Spring Boot、Tomcat）返回的 Cookie 带有原始 Path=，比如 Path=/api 或 Path=/；而用户实际访问的是 Nginx 暴露的路径（如 /app 或 /admin）。若路径不匹配，浏览器不会发送该 Cookie，后续所有安全属性都失去意义。
- 后端返回
Set-Cookie: JSESSIONID=xxx; Path=/api，Nginx 代理到/app→ 配：proxy_cookie_path /api /app; - 后端返回
Path=/，Nginx 代理到/admin→ 配：proxy_cookie_path / /admin; - 该指令必须放在
location块内，且紧接在proxy_pass后，顺序错误或提至server级将失效
用 proxy_cookie_path 注入三属性（推荐主用）
proxy_cookie_path 不仅改路径，还能在末尾追加任意字符串——这是最稳定、无需额外模块、全版本兼容的方式（1.1.12+ 支持）。它直接重写原始 Set-Cookie，避免重复 Cookie 冲突。
- 若后端 Cookie 的
Path=/sub，想保留路径并加属性：proxy_cookie_path /sub "/sub; HttpOnly; Secure; SameSite=Lax"; - 若后端统一设
Path=/，且你代理到根路径：proxy_cookie_path / "/; HttpOnly; Secure; SameSite=Lax"; -
SameSite值按需选Lax（推荐，默认防 CSRF）、Strict（更严）、或None（需同时配Secure）
兜底用 add_header 强制补充（慎用）
当后端返回多个 Cookie、或部分 Cookie 缺 Path= 导致 proxy_cookie_path 不匹配时，可用 add_header 做第二道防线：
- 配置示例：
add_header Set-Cookie "Path=/; HttpOnly; Secure; SameSite=Lax" always; -
always参数确保即使返回 304、5xx 等非 200 响应，该头也生效 - ⚠️ 注意：它会新增一条
Set-Cookie，若后端已设同名 Cookie，可能造成覆盖冲突，仅建议用于简单单 Cookie 场景
高版本可选 proxy_cookie_flags（精细化控制）
Nginx 1.19.3+ 支持 proxy_cookie_flags，支持正则匹配与条件注入，适合复杂策略：
- 例如只对
JSESSIONID加属性：proxy_cookie_flags ~* "JSESSIONID" Secure HttpOnly SameSite=Lax; - 或按域名/路径条件注入，但需确认版本并测试兼容性
