Nginx 通过 proxy_cookie_path 精准重写 Set-Cookie 头以注入 HttpOnly、Secure 和 SameSite 属性，需对齐 Cookie Path 并置于 location 块内 proxy_pass 后；高版本可选 proxy_cookie_flags 实现正则匹配与条件注入。
直接在 Nginx 反向代理层动态注入 HttpOnly、Secure 和 SameSite 属性，关键不是“加头”，而是精准重写后端返回的 Set-Cookie 响应头。Nginx 本身不生成会话 Cookie，但能拦截、解析并替换原始响应中的 Cookie 字段——前提是配置位置正确、指令组合得当、且路径映射无误。
必须先做：用 proxy_cookie_path 对齐 Cookie Path
后端应用（如 Spring Boot、Tomcat）生成的 Cookie 默认按自身部署路径设 Path，比如 Path=/api 或 Path=/；而用户实际访问的是 Nginx 暴露的路径（如 /app 或 /admin）。浏览器只把 Path 匹配当前 URL 路径的 Cookie 发回去，错位即失效。
- 若后端返回
Set-Cookie: JSESSIONID=xxx; Path=/api，你代理到/app，就配：proxy_cookie_path /api /app; - 若后端返回
Path=/，你代理到/admin，就配：proxy_cookie_path / /admin; - 该指令必须放在
location块内，且紧挨proxy_pass后面，顺序错误或提至 server 级均无效
核心操作：用 proxy_cookie_path 注入安全属性
Nginx 的 proxy_cookie_path 不仅改路径，还能追加任意字符串到 Cookie 值末尾。这是最稳定、兼容性最好的注入方式（无需额外模块，1.1.12+ 全支持）。
- 统一为所有根路径 Cookie 添加三项安全属性：
proxy_cookie_path / "/; HttpOnly; Secure; SameSite=Lax"; - 如果后端 Cookie 的
Path是/sub，想保留原路径并加属性，写成：proxy_cookie_path /sub "/sub; HttpOnly; Secure; SameSite=Lax"; -
Secure仅在 Nginx 终止 HTTPS（即 client→Nginx 是 HTTPS，Nginx→backend 是 HTTP）时才安全启用；否则明文链路下设 Secure 会导致 Cookie 被浏览器丢弃
补充加固：用 add_header 强制全局兜底
当后端返回多个 Cookie、或部分 Cookie 未带 Path= 导致 proxy_cookie_path 不匹配时，可用 add_header 做第二道防线——它会额外插入一条 Set-Cookie 头，强制覆盖同名 Cookie 的属性。
- 适用于简单场景（如单会话 Cookie），配置示例：
add_header Set-Cookie "Path=/; HttpOnly; Secure; SameSite=Lax" always; -
always参数确保即使后端返回 304 或 5xx，该头也生效 - 注意：此方式会新增一条 Cookie，若后端已设同名 Cookie，可能造成冲突；建议优先用
proxy_cookie_path方式重写原有头
进阶控制：Nginx 1.19.3+ 推荐用 proxy_cookie_flags
新版 Nginx 提供更精细的 Cookie 标志控制能力，支持正则匹配、条件注入，避免“一刀切”覆盖：
- 只给含
JSESSIONID的 Cookie 加 Secure 和 SameSite：proxy_cookie_flags ~ JSESSIONID Secure SameSite=Lax; - 排除测试环境（非 HTTPS）的 Secure：
proxy_cookie_flags ~* \bJSESSIONID (?:$|;) Secure SameSite=Lax;配合map判断$scheme动态启用 - 需确认 Nginx 版本 ≥ 1.19.3，且编译时未禁用该模块
