referer 在 https 跳转 http 时丢失是浏览器按 referrer policy 主动清空所致，非 nginx 问题；应避免硬依赖 referer 完整值，改用 origin 校验、token 签名或宽松域名匹配，并适配空 referer 场景。
HTTPS 页面跳转到 HTTP 页面时 Referer 丢失，是浏览器主动清空 Referer 的安全行为，不是 Nginx 配置错误，也不能靠 Nginx “恢复”它。关键在于理解机制、规避依赖、调整校验逻辑。
明白 Referer 为什么会丢
当用户从 HTTPS 页面 点击链接跳转到 HTTP 页面 时，浏览器（Chrome/Firefox/Safari）会按 Referrer Policy 默认策略（strict-origin-when-cross-origin）主动清空 Referer 头——只保留源（https://a.com），不发路径；而跨协议降级（HTTPS→HTTP）时，Referer 直接被设为空字符串或完全不发送。这不是传输问题，是客户端强制行为。
- 日志里看到
$http_referer是 "-" 或空，就说明 Referer 没发过来 - Nginx 不生成 Referer，只透传；它无法“补回”浏览器决定不发的内容
- 后端若用完整 Referer URL 做白名单校验（比如比对
https://a.com/login?next=/home），这时必然失败
避免硬依赖 Referer 完整值
把 Referer 当作唯一可信来源验证，本身就不健壮。更合理的做法是分场景解耦校验逻辑：
- 对管理后台类接口（如
/admin/），可配合valid_referers做基础来源过滤，但必须包含none和blocked，否则直接输入 URL 或书签访问也会被拦 - 对 API 接口，优先用
Origin头校验（它不会因协议降级丢失，且不可伪造），搭配map模块做白名单映射 - 关键操作（如支付回调、OAuth redirect_uri）应改用 Token、签名或一次性 code 校验，而非依赖 Referer 路径
后端校验逻辑要适配浏览器策略
如果业务仍需 Referer，后端就不能比对完整 URL，而应支持宽松匹配：
- 只校验协议+域名前缀，例如允许
https://a.com/匹配https://a.com/dashboard和https://a.com/api/v1 - 忽略参数和路径深度，不校验
?ref=xxx或#section - 对 HTTPS→HTTP 场景，可额外接受空 Referer + 其他可信凭证（如 X-Forwarded-For + 登录态 session）组合判断
必要时在 Nginx 层做最小干预
仅当后端短期无法改造，且你明确知道可信来源时，才考虑 Nginx 主动设置 Referer（慎用）：
- 固定可信源：在对应
location块中加proxy_set_header Referer "https://trusted.example.com/"; - 清空 Referer（仅限调试或特殊风控）：
proxy_set_header Referer "";，但会削弱溯源能力 - 绝不写
proxy_set_header Referer $http_referer;—— 浏览器没发，这个变量就是空，等于无效设置
本质上这不是配置问题，而是架构适配问题。浏览器策略不会变，能变的是我们对 Referer 的使用方式。
