Nginx UA屏蔽应前置至server块顶部，优先用map+if替代纯if正则以提升性能；需避免干扰健康检查、IP Hash及运维脚本，结合白名单放行静态资源与协议文件。
在负载均衡场景下，Nginx 对 User-Agent 的屏蔽不能只做简单拦截，需兼顾分发逻辑、性能开销与规则一致性。核心原则是：屏蔽动作应尽量前置、轻量、可复用，避免干扰 upstream 路由决策。
屏蔽应放在 server 层而非 upstream 或 location 内
负载均衡配置（upstream 块）本身不处理请求头匹配，所有 UA 判断必须落在接收请求的 server 块中。若误将 if 指令写在 upstream 外或 location 深层，可能因重写、内部跳转导致规则失效。推荐位置是 server 块顶部，紧接 listen 和 server_name 之后：
- 确保所有进入该虚拟主机的请求第一时间被检查
- 避免 location 匹配后才拦截，节省后续路径解析开销
- 与 proxy_pass 共存时，拦截发生在代理前，不增加后端压力
优先使用 map + if 组合，而非纯 if 正则
高并发下频繁执行正则匹配会带来 CPU 开销。map 指令在 Nginx 启动时编译并缓存匹配逻辑，运行时仅查表，效率更高。适用于负载均衡节点需长期稳定运行的场景：
- 在 http 块顶层定义映射（一次定义，全局可用）：
map $http_user_agent $is_blocked_ua {
default 0;
"~*(Scrapy|Bytespider|Python-urllib|curl)" 1;
"~*MJ12bot|AhrefsBot|Ezooms" 1;
} - 在 server 块中调用：
if ($is_blocked_ua = 1) { return 403; } - map 支持大小写不敏感（~*）、精确匹配（=）、默认值，语法简洁且不易出错
避免与负载均衡策略冲突的常见错误
某些 UA 屏蔽写法会意外破坏健康检查或会话保持逻辑：
- 不要在 location 中屏蔽 UA 后再 proxy_pass —— 若 location 匹配了 /health 或 /status 等监控路径，可能误杀心跳检测
- IP Hash 场景下，若 UA 屏蔽返回 403，客户端重试仍走同一后端，但错误已发生；建议把 UA 检查放在 IP Hash 计算之前（即 server 块开头）
- 禁止对空 UA（
^$）或通用工具 UA（如 curl、wget）直接拦截，除非确认它们不用于运维脚本；否则自动化巡检可能失败
结合业务路径做精细化放行
纯黑名单易误伤，尤其当部分爬虫需访问 robots.txt、sitemap.xml 或静态资源时。可在屏蔽逻辑后补充白名单豁免：
- 用 map 定义允许路径：
map $request_uri $is_allowed_path {
default 0;
"~*\.(js|css|png|jpg|svg)$" 1;
"~^/(robots\.txt|sitemap\.xml)$" 1;
} - 组合判断：
if ($is_blocked_ua = 1) {
if ($is_allowed_path = 0) { return 403; }
} - 这样既挡恶意 UA，又保静态资源和协议文件可被正常抓取
