Nginx默认过滤非标准响应头，需用proxy_pass_header显式放行；每行一个头名，大小写不敏感，仅解除拦截；若曾用proxy_hide_header屏蔽，须先清除再放行；实测需curl -I验证且确认后端真实返回。
在 Nginx 中，默认只透传部分“安全”的响应头（如 Content-Type、Cache-Control 等），而像 X-Request-ID、X-RateLimit-Remaining、Access-Control-Allow-Origin（当由后端动态设置时）等非标准或自定义响应头，会被自动过滤掉。若需显式允许透传后端返回的特定非标头，核心方法是使用 proxy_pass_header 指令。
明确启用指定非标响应头透传
proxy_pass_header 的作用是**取消 Nginx 对某响应头的默认屏蔽**，使其能从上游服务原样传递给客户端。它不添加头、不修改头，仅解除拦截限制。
用法很简单：在 location 或 server 块中直接写：
location /api/ {
proxy_pass https://backend;
proxy_pass_header X-Request-ID;
proxy_pass_header X-RateLimit-Limit;
proxy_pass_header X-RateLimit-Remaining;
}
注意：proxy_pass_header 后跟的是**响应头名（大小写不敏感）**，不是值；每行只能写一个头；它仅对当前作用域生效。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
配合 proxy_hide_header 避免冲突
如果之前用 proxy_hide_header 屏蔽过某个头（例如全局屏蔽了 Server），而你又想在某个 location 下透传另一个同名但来自后端的自定义头（比如后端也用了 Server: MyApp/2.1），这时需先用 proxy_hide_header 清除屏蔽，再用 proxy_pass_header 显式放行：
- 默认情况下，
Server头被 Nginx 自动隐藏； - 若后端确实返回了有意义的
Server值且你想透传，需先写proxy_hide_header Server;（即“取消隐藏”），再写proxy_pass_header Server;； - 更稳妥的做法是：在需要透传的位置，先清空隐式屏蔽，再显式放行。
验证是否生效的实操方式
透传是否成功不能只看配置语法，必须实测响应头：
- 用
curl -I请求目标接口，观察响应头中是否有目标字段； - 检查 Nginx error log，若配置有误（如拼错头名），通常不会报错，但头不会出现；
- 开启
proxy_buffering off;和proxy_http_version 1.1;可减少中间处理干扰，便于调试； - 确认后端实际返回了该头（可用
curl -v http://backend-url直连验证）。
替代方案与注意事项
对于无法用 proxy_pass_header 解决的场景（如头名含下划线、或需重写值），可考虑：
- 用
add_header ... always;手动注入，但这是覆盖而非透传； - 用
proxy_set_header只影响请求头，对响应头无效； - Nginx 1.7.5+ 支持
underscores_in_headers on;，但仅针对请求头，不影响响应头透传逻辑； - 确保后端返回的头名符合 HTTP 规范（建议用连字符分隔，避免下划线——部分客户端或代理可能忽略带下划线的头）。
