多级代理下Origin头丢失本质是Nginx未显式透传原始请求头，需每层location中配置proxy_set_header Origin $http_origin;并开启underscores_in_headers on以支持gray_origin等自定义头，同时统一在最外层Nginx管控CORS响应头。
多级代理下Origin头丢失，本质是Nginx在逐层转发时未显式透传原始请求头，加上默认过滤规则和配置作用域错位，导致下游服务收不到Origin，进而无法做源校验或动态返回CORS头。关键不是“头被删了”，而是“压根没传下去”。
确认Origin是否真的到达第一层Nginx
用curl模拟真实请求，带上Origin头直连最外层Nginx：
-
执行命令：
curl -v -H "Origin: https://example.com" http://your-nginx-ip/api/test - 检查Nginx访问日志（如
log_format中含$http_origin）是否记录该值；若为空，说明客户端根本没发，或中间有CDN/负载均衡提前剥离了Origin - 若日志有值，但后端收不到，则问题出在Nginx转发链路上
修复多级代理中Origin的逐层透传
Origin是标准HTTP请求头，但Nginx默认不自动转发所有头——尤其在多级代理中，每一跳都需主动声明：
- 每层Nginx的
location块中必须加：proxy_set_header Origin $http_origin; - 确保
proxy_pass_request_headers on;已启用（虽默认为on，显式写出更稳妥） - 若某层Nginx做了重写（如
rewrite或proxy_redirect），需确认未意外覆盖或清空$http_origin变量
处理含下划线的自定义Origin相关头（如gray_origin）
部分灰度或内部系统会用gray_origin等带下划线的头替代标准Origin。Nginx默认丢弃这类头：
- 在
http或server块顶部统一开启：underscores_in_headers on; - 再在
location中显式透传：proxy_set_header gray_origin $http_gray_origin; - 注意：不能只开
underscores_in_headers就以为万事大吉——仍需proxy_set_header显式转发，否则不生效
避免CORS头污染与重复设置
Origin丢失常伴随另一个问题：后端或中间层误加Access-Control-Allow-Origin，导致Nginx叠加响应头报错。此时Origin虽存在，但响应被浏览器拒绝：
- 关闭所有后端服务的CORS自动注入（如Spring Boot的
@CrossOrigin、Express的cors()中间件） - 在最外层Nginx统一控制CORS：用
map白名单校验$http_origin，再用add_header ... always单值输出 - 加
proxy_hide_header Access-Control-Allow-Origin;防止内层代理或后端透传旧头干扰
