blocked 参数用于放行被剥离但非伪造的 Referer 请求，如仅含域名、路径或 null 等异常格式，使其不触发 $invalid_referer=1；它与 none 并列作为 valid_referers 的白名单项，不降低安全性。
blocked 参数不是用来“拦截”被剥离 Referer 的请求，而是放行这类请求。
它解决的是一个常见但容易被误解的问题：某些网络环境会把原始 Referer 修改成不完整、不可用的形式（比如只留域名、去掉协议、或变成空路径），导致 valid_referers 匹配失败，进而误拦合法用户。blocked 就是专门为此类“被剥离但非伪造”的 Referer 设计的白名单项。
为什么需要 blocked
浏览器或中间设备可能让 Referer 变成以下形式之一，Nginx 默认无法识别为合法来源：
-
example.com（缺协议，如https://） -
/path/to/page（只有路径，无域名） -
null或空字符串（部分隐私插件、企业代理、防火墙策略）
这些情况在 Nginx 看来不属于 none（完全无 Referer），也不匹配你写的 example.com 或正则，所以 $invalid_referer 会被设为 1 —— 若没加 blocked，就会被错误拦截。
blocked 的实际作用方式
-
valid_referers指令本身不拦截，只设置$invalid_referer变量值； - 当请求头中
Referer存在，但内容不符合任何显式规则（如域名、正则），且其值属于“被截断/被清理”类型时，blocked会让 Nginx 认为该请求可接受； - 结果：
$invalid_referer = 0，后续if ($invalid_referer)不触发，请求正常处理。
✅ 正确写法示例：
location ~* \.(jpg|png|js|css)$ {
valid_referers none blocked *.myapp.com myapp.com;
if ($invalid_referer) {
return 403;
}
}这里 blocked 和 none 是并列的白名单项，语义是：“允许 Referer 完全缺失（none），也允许 Referer 存在但被清理得只剩片段（blocked）”。
如何验证 blocked 是否生效
用 curl 模拟几种典型被剥离场景：
# 场景1：Referer 只有域名（无协议） curl -H "Referer: myapp.com" https://your.site/image.jpg # 场景2：Referer 是路径形式（常见于某些代理） curl -H "Referer: /login" https://your.site/image.jpg # 场景3：Referer 为 null（部分浏览器扩展行为） curl -H "Referer: null" https://your.site/image.jpg
只要 valid_referers 中包含 blocked，上述请求都不会触发 return 403。
⚠️ 注意：blocked 不代表“放行任意非法 Referer”，它只覆盖特定格式的异常值，不会削弱白名单逻辑的安全性。
常见误区提醒
- ❌ 把
blocked当作兜底通配符（比如以为加了它就能放行baidu.com）→ 实际不会匹配； - ❌ 和
if混用不当，比如在if外部写return→ 规则失效； - ❌ 忘记
none和blocked都要显式声明 → 直接输入 URL 或 HTTPS 跳 HTTP 图片会 403； - ❌ 在
http或server块里写valid_referers→ 必须放在具体静态资源的location块内才生效。
不复杂但容易忽略。
