nginx中if ($http_user_agent ~* "scrapy")在location内不生效，因if在location中执行受限且易被覆盖，官方不推荐嵌套使用；正确做法是将规则置于server块顶层，并用map预定义变量提升可靠性与性能。
直接结论：Nginx 用 $http_user_agent 配合 if + 正则匹配就能拦截指定 UA，但必须放在 server 块顶层（不能嵌套在 location 内），且要小心误杀合法流量。
为什么 if ($http_user_agent ~* "scrapy") 在 location 里不生效
Nginx 的 if 指令在 location 块内行为受限：它只在进入该 location 后才执行，而 return 或 rewrite 可能被后续配置覆盖；更关键的是，多个 if 嵌套时逻辑不可靠，官方明确不推荐。
- 正确位置是
server块最外层（listen和server_name下方即可） - 错误写法示例：
location /api { if ($http_user_agent ~* "curl") { return 403; } }—— 这里if会被忽略或触发未定义行为 - 若需按路径差异化拦截（如只拦
/admin），应把规则写在对应location外的server块中，再用变量标记，而非在location内写if
$http_user_agent 匹配时大小写和空格怎么处理
~* 表示不区分大小写，~ 是区分大小写；UA 字符串里常含空格、括号、斜杠，正则中需转义。
- 匹配
Mozilla/5.0 (Windows NT 10.0; Win64; x64)这类标准 UA 不用转义，但含特殊字符的必须加反斜杠："Mozilla/4\.0 \(compatible; MSIE 6\.0;.*\)" - 匹配空 UA 要用
= ""（精确匹配），不是正则：if ($http_user_agent = "") { return 403; } - 避免写
~ "python|java|go"这种宽泛模式——python会命中Python-urllib，但也可能误伤CPython或内部监控脚本
哪些 UA 绝对不该直接拦截
盲目封禁含 bot、spider 的 UA 会导致搜索引擎无法收录，甚至阻断 CI/CD 工具链。
- 必须放行：
Googlebot、Bingbot、YandexBot、Applebot（iOS 网页预加载）、Twitterbot - 内部工具常见 UA（需白名单）：
Zabbix、Prometheus/Alertmanager、Github-Hookshot、GitLab-CI - 推荐做法：先建一个
$allowed_ua变量做白名单匹配，再用if拦黑，而不是“非白即黑”
拦截后返回 403 还是 444？日志怎么留痕
return 403 返回标准拒绝响应，return 444 是 Nginx 特有状态码，直接关闭 TCP 连接，不发任何字节——更隐蔽，也省带宽。
- 用
444时注意：部分客户端（尤其老版本 curl）可能报连接重置，不利于调试；生产环境建议先用403观察一周 - 必须加日志字段，否则查不到谁被拦了：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $blocked_ua'; - 可配合
map提前标记：map $http_user_agent $blocked_ua { ~*(scrapy|curl|headlesschrome) "1"; default ""; }，再在if中判断$blocked_ua = "1"
真正难的不是写几行 if，而是持续维护 UA 规则、区分真实爬虫和合法自动化工具、以及避免因拦截导致监控告警失灵。上线前务必用 curl -A "Scrapy/2.11.2" 和 curl -A "Googlebot/2.1" 分别验证黑白名单效果。
