nginx的proxy_set_header默认覆盖同名请求头，仅对允许多值且被识别的头部（如cookie）可手动拼接合并；host不合并，cookie会完全替换，需用$http_cookie和map构造新值实现追加。

Nginx 的 proxy_set_header 默认不会“合并”请求头，而是**覆盖或追加**——具体行为取决于头字段是否允许多值、客户端原始请求中是否存在、以及 Nginx 版本和配置上下文。所谓“头字段合并”，实际是指在代理转发时，把多个来源的值（如原始请求头 + 自定义值）组合成一个合法的多值头（例如多个 Cookie 或 Accept-Encoding），而非简单覆盖。

理解 proxy_set_header 的默认行为

proxy_set_header 每次出现都会为该 header 设置一个值；若同一 header 多次设置，后出现的指令会覆盖前一个（除非该头天然支持多值且 Nginx 识别其语义）。

但有两个关键例外：

• Host：若未显式设置，Nginx 默认用 $proxy_host；若设置了，就以设置值为准，不合并原始 Host。
• Cookie：Nginx 不自动合并多个 Cookie 头。原始请求若有多个 Cookie: a=1 和 Cookie: b=2，后端收到的是两个独立头（HTTP/1.1 允许），但多数后端会自动合并解析。而 proxy_set_header Cookie "c=3" 会完全替换所有原始 Cookie 头。

手动实现“合并效果”的常用方法

要真正合并（比如保留原始 Cookie 并追加新字段），需借助变量拼接：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 用 $http_cookie 获取原始 Cookie 值（注意：它只取第一个 Cookie 头，且已解码）；
• 用 map 或 set 构造新值，例如：
    map $http_cookie $merged_cookie {
      default "$http_cookie; d=4";
      "" "d=4";
    }
• 再通过 proxy_set_header Cookie $merged_cookie 透传。

类似逻辑也适用于 User-Agent、Accept-Encoding 等允许重复的头字段。

利用 add_header（仅限响应头，不适用 proxy 场景）

add_header 支持多次出现并生成多个同名响应头，但它作用于 Nginx 返回给客户端的响应，不影响 proxy_pass 发送给上游的请求头。所以它不能用于实现 upstream 请求头的“合并”。

注意 HTTP/2 和头压缩的影响

在 HTTP/2 代理中，Nginx 会将多个同名请求头（如多个 Cookie）合并为一个逗号分隔的字符串再编码（HPACK）。但这个行为由协议栈处理，不可控。若需确保格式一致，仍建议在 Nginx 层统一拼接后再设置，避免依赖协议层隐式合并。