最稳妥的做法是让Nginx主动接管关键响应头，即先用proxy_hide_header拦截后端不可控头（如Access-Control-Allow-Origin、Strict-Transport-Security、Transfer-Encoding、Cache-Control等），再用add_header（推荐加always参数）统一注入合规头；跨域头需避免*与credentials冲突，HSTS仅HTTPS下启用，OPTIONS预检请求应由Nginx直接返回204，并确保HTTP/1.1协议配置正确。
最稳妥的做法是让 Nginx 主动接管关键响应头，而不是和后端“共管”。后端返回的某些头（比如跨域、安全、缓存、协议相关头）若与 Nginx 配置叠加，浏览器或中间层会直接拒绝响应，出现 502、跨域失败、缓存失效等现象。核心逻辑就一条：先清再加——用 proxy_hide_header 拦截后端不可控的头，再由 Nginx 用 add_header 或其他指令统一、干净地注入。
明确哪些头必须屏蔽
不是所有响应头都需要干预，重点盯住这几类易冲突的头：
- 跨域类：
Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等 - 安全类：
Strict-Transport-Security、X-Frame-Options、X-XSS-Protection、X-Content-Type-Options、Content-Security-Policy - 协议类：
Transfer-Encoding、Connection、Content-Length（尤其当后端主动设 chunked 时） - 缓存类：
Cache-Control、Expires（若后端策略混乱或格式错误）
这些指令必须写在 location 块内，且放在 proxy_pass 之后才生效。例如：
location /api/ {
proxy_pass http://backend;
proxy_hide_header Access-Control-Allow-Origin;
proxy_hide_header Strict-Transport-Security;
proxy_hide_header Transfer-Encoding;
proxy_hide_header Cache-Control;
}统一注入时注意关键细节
清掉旧头后，Nginx 必须主动补上合规、可控的新头：
- 跨域头务必加
always参数，否则 4xx、5xx、204 等非 200 响应不带跨域头，前端拿不到错误详情 -
Access-Control-Allow-Origin不要用*配Access-Control-Allow-Credentials: true，应动态匹配$http_origin或明确白名单 - HSTS 头只应在 HTTPS 下注入，可用
if ($scheme = https)控制 - 缓存头如
Cache-Control推荐用add_header ... always显式设定，配合proxy_cache_valid兜底
预检请求和协议头要单独处理
浏览器发 OPTIONS 请求时，别让它穿透到后端：
if ($request_method = 'OPTIONS') {
add_header Access-Control-Max-Age 1728000;
add_header Content-Length 0;
return 204;
}同时确保 proxy_http_version 1.1 和 proxy_set_header Connection "" 同时启用，解决 upstream sent invalid chunked response 类错误——这是 HTTP/1.0 与 HTTP/1.1 协议协商失败的典型表现。
验证是否真正生效
别只看配置文件，用真实请求验证：
-
curl -I http://your-domain/api/xxx查响应头，确认旧头已消失、新头已存在 - 检查 Nginx error log，搜索
duplicate header、invalid header、upstream sent等关键词 - 查 access log 中
$upstream_cache_status字段，确认缓存行为符合预期
不复杂但容易忽略
