nginx反向代理中不应伪造referer头，而应通过x-source-app等可信头透传来源信息、对可控入口谨慎补全referer，或推动后端升级为多因子鉴权，以兼顾安全与兼容性。
Nginx 作为反向代理时，不能也不应该用 proxy_set_header Referer ... 主动伪造 Referer 头去“适配”后端防盗链——这会破坏 Referer 的真实性，违背防盗链设计初衷，且可能绕过安全策略、引发误判或审计风险。
但如果你的场景是：已有后端服务依赖 Referer 鉴权（如校验来源域名），而上游客户端（如 App、微信内嵌页、HTTPS 页面引用 HTTP 资源）天然不带或清空了 Referer，导致合法请求被拦截，那么你需要的是「可信来源标识的平滑透传或可信补充」，而非伪造。以下是真正可行、安全、符合运维实践的三种方式：
✅ 方式一：用真实可信字段替代 Referer（推荐）
后端防盗链逻辑应升级为支持多源校验，Nginx 通过 proxy_set_header 传递更可靠的标识：
- 用
X-Real-IP或X-Forwarded-For+ 白名单 IP 段判断来源 - 用自定义可信头（如
X-Source-App: wechat）配合后端 UA/IP/Token 多因子验证 - 若必须模拟“来源站”，可设
X-Referer-Site: your-main-site.com（后端需主动读取该头，而非依赖原始 Referer）
location /api/assets/ {
proxy_pass https://backend;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Source-App "web";
# 不覆盖原始 Referer，仅追加可信上下文
}
⚠️ 后端需改造：不再只查
Referer，而是优先检查X-Source-App+X-Real-IP白名单，Fallback 到 Referer 校验。
✅ 方式二：对特定可信入口补全 Referer（谨慎使用）
仅适用于你完全可控的入口（如自己的 H5 页面、管理后台），且能确保不会被滥用：
# 仅当请求来自你自己的域名，且无 Referer 时，补一个可信值
if ($invalid_referer = "1") {
set $my_referer "https://your-admin.example.com";
}
if ($http_host ~ "^admin\.example\.com$") {
proxy_set_header Referer $my_referer;
}
但注意：
- 必须配合
valid_referers none blocked your-admin.example.com;做前置校验 - 不能对公网开放的 location 使用，否则等于开放 Referer 注入漏洞
- 更稳妥做法是前端在请求时显式带上
Referer: https://your-admin.example.com
❌ 方式三：直接 proxy_set_header Referer xxx（不推荐）
例如：
proxy_set_header Referer "https://your-site.com";
这会导致：
- 所有经过该 proxy 的请求 Referer 被统一覆盖 → 后端无法区分真实来源
- 破坏统计、AB 测试、来源分析等依赖 Referer 的业务逻辑
- 若后端同时校验 Referer 和签名，可能因 Referer 固定导致签名失效
- 违反 HTTP 协议语义，属于误导性代理行为
? 关键提醒
-
Referer是浏览器自动携带的客户端线索，不是认证凭证；防盗链本质是“粗粒度过滤”，非强安全机制 - 真正需要防的不是“盗链”，而是“未授权高频资源访问”——建议后端结合 Token（如时间戳+签名 URL）、User-Agent、频率限流、登录态校验等组合策略
- 如果后端坚持只认 Referer，最可持续的方案是：推动后端支持
X-Forwarded-Host/X-Original-Referer等扩展头，或迁移到基于 JWT 的资源访问令牌
不复杂但容易忽略：平滑接入的核心，从来不是让 Nginx “撒谎”，而是让前后端约定一种更可靠、可验证的通信契约。
