proxy_set_header只修改发往后端的请求头，不处理响应头；控制响应头需用add_header添加/覆盖、proxy_hide_header屏蔽后端头，二者作用方向截然不同。
proxy_set_header 不是用来优化“响应头”的，它只负责设置**转发给后端的请求头**。想控制返回给客户端的响应头，得用 add_header 或 proxy_hide_header 等指令。混淆这两类指令是常见误区。
明确作用边界：请求头 vs 响应头
proxy_set_header 只影响 Nginx 发往后端服务的那一次 HTTP 请求——它修改的是“出站请求”的头部。后端返回的响应头（比如 Content-Type、Cache-Control、X-Powered-By）默认会原样透传给客户端，Nginx 不干预，除非你主动配置：
-
add_header：在响应中添加或覆盖响应头（注意：仅对 2xx 和 3xx 生效，4xx/5xx 默认不生效，需加
always参数） -
proxy_hide_header：屏蔽后端返回的特定响应头（如隐藏
Server或X-Powered-By） - proxy_pass_request_headers off：极少用，禁用请求头透传（一般不推荐）
高频实用场景与写法
真正影响客户端体验的响应头控制，集中在以下几类：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
安全加固：屏蔽敏感信息
proxy_hide_header Server;proxy_hide_header X-Powered-By; -
CORS 支持：动态传递 Origin 并设置响应头
proxy_set_header Origin $http_origin;add_header 'Access-Control-Allow-Origin' $http_origin;add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; -
缓存策略：强制不缓存或设定有效期
add_header Cache-Control "no-store, no-cache, must-revalidate";add_header Pragma "no-cache";add_header Expires "0"; -
HTTPS 一致性：确保后端知道原始协议
proxy_set_header X-Forwarded-Proto $scheme;
后端据此生成正确跳转链接或资源地址，避免混合内容警告
容易踩坑的细节
几个关键点直接影响效果：
- add_header 不继承：在 location 中定义的 add_header 不会自动继承到子 location，需重复写或提至 server 块
-
重复响应头被覆盖：若后端和 Nginx 都设了同一响应头（如 Content-Security-Policy），以 后端返回的为准；要用
add_header覆盖，必须配合proxy_hide_header先屏蔽后端的 -
$http_xxx 变量为空时行为：比如
$http_origin在非跨域请求中为空，直接用于 add_header 可能导致无效值，建议搭配 map 指令做兜底
WebSocket 场景下的特殊处理
启用 WebSocket 代理时，必须透传升级协议头，否则连接失败：
proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";- 这两条必须成对出现，且
Connection的值必须是字面量"upgrade"，不能用变量
