最有效方式是通过Nginx日志实时监控特定User-Agent的高频访问并动态限流。需配置JSON结构化日志，按UA统计请求频次、状态码及响应时间；对异常UA结合IP与UA双维度限流；再通过定时脚本自动识别并封禁持续高频恶意UA。
直接通过 Nginx 日志监控特定 User-Agent 的高频访问，是发现并防御其引发资源耗尽最有效的方式。关键不在于“拦住所有爬虫”，而在于识别异常行为模式——比如某个 UA 在极短时间内发起大量连接或请求，远超正常用户或合规爬虫的合理范围。
实时日志分析：定位可疑 UA
Nginx 默认 access_log 记录了 $http_user_agent、$remote_addr、$request_time、$status 等字段。启用结构化日志（如 JSON 格式）可大幅提升分析效率：
- 在
http块中添加自定义日志格式：log_format json_log '{"time":"$time_iso8601","ip":"$remote_addr","ua":"$http_user_agent","status":$status,"req_time":$request_time,"uri":"$uri"}'; - 将 access_log 指向该格式：
access_log /var/log/nginx/access.json json_log; - 用工具（如 awk + sort + uniq 或 ELK / Grafana Loki）按 UA 统计每分钟请求数、4xx/5xx 比例、平均响应时间。例如：
awk -F'"' '/"ua":"/ {print $4}' /var/log/nginx/access.json | sort | uniq -c | sort -nr | head -20
若发现某 UA（如 python-requests/2.31.0 或空 UA）每分钟请求超 500 次，且 90% 返回 200 但平均耗时低于 10ms，基本可判定为自动化扫描或低质爬虫。
动态限流：比硬拦截更稳妥
对高频 UA 不建议直接 return 403，尤其当它可能被伪造或误伤真实客户端。应结合 IP + UA 双维度做分级限流：
- 在
http块定义两个限流区域：limit_req_zone $binary_remote_addr zone=ip_rate:10m rate=10r/s;limit_req_zone "$http_user_agent" zone=ua_rate:10m rate=3r/s; - 在
location中叠加应用：limit_req zone=ip_rate burst=20 nodelay;limit_req zone=ua_rate burst=5 nodelay; - 这样既防单 IP 暴力刷，也压住某个 UA 的整体调用量，避免因 UA 字符串过长或含特殊字符导致匹配失效的问题。
自动封禁联动：从监控到阻断
单纯看日志滞后，需构建闭环响应。推荐轻量级方案：
- 写一个定时脚本（如每 2 分钟执行），用
awk或 Python 解析最新 access.log，筛选出满足条件的 UA：
– 连续 3 次采样中，每分钟请求 ≥ 300
– 且 404/403 占比 - 将命中 UA 写入临时黑名单文件（如
/etc/nginx/conf.d/blocked_ua.conf），内容为：if ($http_user_agent ~* "python-requests|go-http-client|curl/7.81") { return 403; } - 在主 server 块中
include blocked_ua.conf;，然后执行nginx -t && nginx -s reload - 注意：黑名单需设 TTL（如 2 小时后自动清理），防止误封长期有效 UA（如某些 API 客户端）。
辅助加固：降低 UA 依赖风险
User-Agent 极易伪造，不能作为唯一判断依据。必须搭配其他信号增强可信度：
- 检查请求头是否缺失关键字段（如
Accept、Accept-Language），真实浏览器几乎不会为空； - 对疑似 UA 的请求，额外校验
$request_method和$request_uri—— 若大量 POST 到静态资源路径（如/js/app.js），基本可判为扫描器； - 开启
limit_conn限制单 IP 并发连接数（如limit_conn conn_per_ip 15;），即使 UA 被绕过，也能卡住连接层资源。
