proxy_set_header origin $http_origin 用于透传原始请求的origin头给后端，确保后端准确识别来源；而跨域响应头必须用add_header设置，如access-control-allow-origin $http_origin，二者作用对象与目的截然不同。
proxy_set_header 本身不用于让后端“感知跨域来源”——它只负责把请求头传给后端，而浏览器是否跨域、是否触发 CORS 校验，完全由前端发起请求时的 Origin 决定，后端靠读取 Origin 头来识别来源。所以关键不是“感知跨域”，而是确保后端能稳定、准确地收到原始 Origin 值。
必须透传 Origin 头
默认情况下，Nginx 反向代理不会自动传递 Origin 头（尤其当客户端是浏览器跨域请求时）。若不显式设置，后端收到的 Origin 可能为空或丢失，导致鉴权失败、登录态校验异常等。
- 正确写法：
proxy_set_header Origin $http_origin; - $http_origin 是 Nginx 自动提取的客户端请求中 Origin 头的值，原样透传即可
- 该指令需放在
proxy_pass之前，且不能被其他同名 header 覆盖 - 若客户端没发 Origin（如普通页面跳转、curl 直连），$http_origin 为空，Nginx 不会额外添加 Origin 头，符合 HTTP 规范
避免 Origin 被意外覆盖或清空
某些场景下 Origin 可能被中间层（如 CDN、WAF）抹除，或 Nginx 配置中误写成固定值，导致后端始终看到错误来源。
- 不要写
proxy_set_header Origin "https://myapp.com";—— 这会强制所有请求都带上固定 Origin，破坏真实来源识别 - 检查上游是否已清除 Origin：若使用 Cloudflare 或阿里云 WAF，确认其未默认 strip Origin 头
- 配合日志验证：
log_format main '$remote_addr - $http_origin "$request"';，在 access_log 中观察 Origin 是否正常记录
配合 add_header 实现完整 CORS 流程
仅透传 Origin 不够——后端还需要告诉浏览器“允许这个来源”。这部分由响应头控制，必须用 add_header，而非 proxy_set_header：
-
add_header Access-Control-Allow-Origin $http_origin;—— 动态回显原始来源（需搭配 credentials 使用时，不能为 *） -
add_header Access-Control-Allow-Credentials "true";—— 若涉及 Cookie 或认证头 -
add_header Vary "Origin";—— 防止缓存混淆，尤其当 Origin 动态变化时
特殊场景：SPA 路由跳转后 Origin 为空怎么办？
单页应用通过 History API 跳转时，AJAX 请求可能不带 Origin（例如 fetch 未显式指定 credentials 或 mode）。这不是 Nginx 的问题，但会影响后端判断。
- 前端应确保跨域请求显式设置：
fetch(url, { credentials: 'include', mode: 'cors' }) - 后端不可仅依赖 Origin 判断合法性；建议结合 Token、Referer（需 proxy_set_header Referer $http_referer）、或自定义 header（如 X-Request-From）做辅助校验
- Nginx 可同步透传 Referer：
proxy_set_header Referer $http_referer;，作为 Origin 缺失时的补充依据
