nginx 实现 referer 与 token 分层校验：先用 valid_referers 快速拦截非法来源，再对高风险路径用 map 或 secure_link 验证 token，兼顾性能与安全。
单纯校验 Referer 安全性有限，因为该字段可被轻易伪造；而只依赖 Token 又可能增加前端负担或暴露验证逻辑。Nginx 层实现 Referer + Token 的双重校验，不是“同时满足”，而是构建分层拦截：先快速筛掉明显非法请求（如 Referer 不匹配），再对可疑或关键路径做 Token 验证，兼顾性能与安全性。
Referer 白名单作为第一道过滤
在 location 块中用 valid_referers 定义可信来源，保留 none 和 blocked 以兼容直接访问、代理转发等合法无 Referer 场景。不匹配即返回 403，避免后续处理开销。
- 只对静态资源或低风险接口启用，例如：
location ~* \.(jpg|png|css|js)$ - 白名单写法示例：
valid_referers none blocked *.example.com example.com; - 判断并拦截：
if ($invalid_referer) { return 403; }
Token 参数校验需结合 map 与 if 判断
Nginx 原生不支持解析 query string 中的 token 并验签，但可通过 map 提取参数值，再用 if 做简单比对（适用于固定 secret 场景）；更安全的做法是配合 secure_link 模块生成有时效、带签名的链接。
- 提取并比对固定 token：
map $arg_token $token_valid { "abc123" 1; default 0; }，然后if ($token_valid = 0) { return 403; } - 若需防重放、有时效性，启用 secure_link：用后端生成
secure_link_md5签名，Nginx 验证$arg_st和$arg_e（过期时间），自动拒绝过期或篡改链接 - 注意：
$arg_xxx只读取 query string，POST 请求中的 token 需通过$request_body解析——这需搭配 Lua 或 OpenResty，纯 Nginx 不支持
组合策略：按路径分级启用
不要在所有 location 下硬性要求两者都存在，应区分资源敏感度。高风险操作（如下载凭证、管理接口）才启用 Token 校验；图片、样式等静态资源只需 Referer 保护即可。
- 示例结构：
location /api/v1/download/ { ... # 启用 secure_link } location ~* \.(jpg|png)$ { ... # 仅 valid_referers + 缓存头 }- 日志中记录
$http_referer和$arg_token，便于观察真实流量构成，及时发现绕过行为
必须避开的常见误区
Referer 和 Token 都不是银弹。配置时需清醒认知其边界：
- 浏览器发起的跨域 AJAX 请求，若未显式设置
credentials: true，Referer 可能被清空；HTTPS 页面加载 HTTP 资源时，Referer 也会被截断 - 移动 App、微信小程序、桌面客户端默认不发 Referer，若强制校验会导致功能中断
- Token 若明文传递（如
?token=xxx），会出现在 access_log、CDN 日志、浏览器历史中，存在泄露风险 - Nginx 的 if 在 location 中虽可用，但不支持嵌套逻辑；复杂判断建议交由后端完成，Nginx 只做轻量预筛
