strict-origin-when-cross-origin是浏览器默认referer策略，同源发完整url，跨域仅发源（协议+域名+端口），降级（https→http）不发referer，兼顾安全与功能。
Strict-Origin-When-Cross-Origin 是浏览器默认的 Referer 策略，它本身不是跨域错误，也不会直接导致请求失败；但它会让跨域请求只携带源（scheme+host+port），不带路径和参数。如果后端依赖完整 Referer 做白名单校验、OAuth 回调匹配或日志溯源，就可能误判为“来源非法”而拒绝请求——这时问题出在业务逻辑，而非 CORS 配置没生效。
明确 Referer 丢失不是 Nginx 的锅
Nginx 不生成 Referer，只透传、改写或清除客户端发来的 Referer 头。浏览器按策略决定发什么，Nginx 只是中转站。所以不能指望 Nginx “修复” Referer 内容，而应聚焦于：是否真需要完整 URL？能否让后端适配更宽松的校验？
合理配置 Nginx 的 Referer 行为
根据实际场景选择一种方式，避免盲目清空或硬编码：
-
默认透传（推荐）：不加任何
proxy_set_header Referer指令，让浏览器按 strict-origin-when-cross-origin 规则自然发送，最符合安全规范 -
固定可信源：若后端只认某个固定域名（如
https://admin.example.com），可在 location 中设置：proxy_set_header Referer "https://admin.example.com/"; -
清空 Referer（慎用）：仅当后端明确要求无 Referer 且无法改造时使用：
proxy_set_header Referer "";（注意：这会削弱部分安全追踪能力）
优先推动后端升级校验逻辑
比起在 Nginx 层打补丁，更可持续的解法是调整后端验证方式：
- 将 Referer 校验改为 Origin 头匹配（如检查
Origin: https://a.com是否在白名单内），Origin 天然不含路径，与浏览器策略一致 - 对关键接口启用 Token 或 API Key 认证，完全绕过 Referer 依赖
- 若必须用 Referer，后端应支持前缀匹配（如
https://a.com/），而非比对完整 URL（https://a.com/login?next=/home）
验证是否生效的小技巧
用 curl 模拟跨域请求，快速确认服务端收到的 Referer 是什么：
- 模拟 HTTPS 跨域请求：
curl -H "Origin: https://client.com" -I https://your-api.com/api/data - 对比响应头中的
Referer（实际不会出现，因为 curl 不自动发）和后端日志里记录的值，重点看服务端 log 是否收到预期内容 - 浏览器开发者工具 Network 标签页中，选中请求 → Headers → Request Headers，查看
Referer字段真实值
