Nginx默认不合并重名响应头，而是原样透传；真正可控的“合并”需先用proxy_hide_header屏蔽原始头，再由Nginx统一构造新值，避免冲突并确保语义清晰。
Nginx 默认不合并后端响应头中的重名字段，而是原样透传——多个同名响应头（如多个 Set-Cookie）会以独立行形式发给客户端。浏览器通常能正确解析，但部分后端或中间件可能只读取第一个值，导致逻辑异常。真正需要“合并”，其实是**统一控制格式、避免冲突、确保语义清晰**，而不是让 Nginx 自动拼接。
哪些头天然允许多值且会被浏览器合并
HTTP 协议允许某些响应头重复出现，浏览器/客户端会自动聚合处理：
- Set-Cookie：每个都是独立 cookie，必须分开发送；不能合并成一个头
- Vary、Accept-Ranges、WWW-Authenticate：允许多值，用逗号分隔，Nginx 不干预，后端应自行规范格式
- Access-Control-Allow-Headers 等 CORS 头：若后端多次设置，浏览器按最后一个生效（非合并），易被覆盖
为什么不能靠 proxy_set_header 或 add_header 合并响应头
proxy_set_header 只作用于发往后端的请求头，对响应头无效；add_header 是新增响应头，每次声明都会覆盖前一次同名头（除非加 always 且未重复写同一指令），它不读取、不解析后端返回的原始头，更无法做字符串拼接。
例如：
X-Trace-ID 头（如果 Nginx 版本支持多值输出），但多数情况下是后者覆盖前者：add_header X-Trace-ID "abc";<br>add_header X-Trace-ID "def";
真正可控的合并策略：拦截 + 重构
要实现“合并效果”，需先屏蔽原始头，再由 Nginx 构造新值。适用于需归一化、去重、追加或格式标准化的场景：
- 用
proxy_hide_header Set-Cookie屏蔽所有原始Set-Cookie，再用 Lua 脚本提取、去重、拼接后调用ngx.header["Set-Cookie"] = {...} - 对
Access-Control-Allow-Headers，先proxy_hide_header，再add_header Access-Control-Allow-Headers "Origin, Content-Type, Authorization" always; - 若需动态合并多个
X-Forwarded-For值（虽属请求头，但逻辑类似），可用map+$http_x_forwarded_for构造新变量，再proxy_set_header
推荐做法：源头治理优于代理层合并
响应头重名问题本质是后端行为不规范。比起在 Nginx 层复杂拼接，更可持续的方式是：
- 要求后端服务对多值头（如
Set-Cookie、Link）保持单次调用、批量设置 - 禁用调试类重复头（如
X-Debug-Info、X-RateLimit-Remaining多次写入） - 使用 OpenResty 的
header_filter_by_lua_block实现条件合并（如仅当状态码为 200 时合并X-Data-Sources）
