前几天查服务器访问日志时看到一个非常典型的场景同一批 IP 在短短几个小时内发起上万次请求User-Agent 指向 Amazonbot请求路径覆盖了首页、列表页、搜索接口甚至一些隐私性较强的后台路径。更让人警觉的是robots.txt里已经明确写了Disallow: /但这个爬虫仍然在继续抓取。这个现象不是个例。很多站长在运维日志分析中都会遇到类似问题某个爬虫根本不理会robots.txt而是按自己的节奏扫描站点。面对这种情况只靠改robots.txt是没有意义的因为从协议设计上讲它本来就没有强制约束力。真正有效的防御必须在服务器层面、网络层面和监控层面同时展开。这篇文章会围绕 Amazonbot 这个具体案例把三个问题讲清楚怎么确认爬虫身份、怎么配置多层封禁、怎么验证封禁真的生效。读完以后你可以照着配置一套适合自己站点的“反爬虫防御方案”也能在下次遇到其它爬虫时复用同一套分析思路。1. 这个问题为什么值得关注1.1 爬虫流量对服务器资源的影响爬虫流量和正常用户流量的最大区别在于用户会浏览、思考、点击而爬虫会持续并发请求。当一个爬虫以每分钟几十上百次的频率请求站点时即使单次请求的响应只有几十毫秒也会快速消耗 PHP-FPM 进程、数据库连接池和带宽资源。放在一台低配云服务器上这种流量很容易把 CPU 打到 100%导致正常用户访问变慢甚至超时。如果是按流量计费的 CDN 或对象存储账单也会明显上涨。很多站长一开始以为是“网站代码有性能问题”排查半天才发现罪魁祸首是日志里高频出现的 UA。所以第一件事不是优化业务代码而是先搞清楚流量里到底有哪些非人类请求。1.2 为什么 Amazonbot 值得单独讨论从公开信息来看Amazonbot 是亚马逊官方搜索引擎和 AI 训练数据抓取用的网络爬虫它的来源 IP 基本归属在亚马逊的云基础设施上。这类大型公司级爬虫通常理论上会遵守协议但从大量站长的运维反馈来看它确实存在忽略robots.txt、高频抓取、请求路径超出必要范围的情况。这意味着我们不能用“大公司爬虫应该守规矩”的假设来替代实际防护。凡是能给站点带来资源压力的客户端都应该当作“潜在的不可信流量”来看待。1.3 哪些站点最容易受影响从实际受影响的站点类型来看以下几类最容易中招内容型站点尤其是页面 URL 规则简单、静态页较多的博客和资讯站搜索接口没有做鉴权或限流的 Web 应用没开 CDN 或 WAF源站 IP 直接暴露的服务器日志保留时间短无法回溯攻击或爬虫行为的站点。如果你的站点刚好命中以上几条这篇文章的配置思路可以直接套用。2. robots.txt 的原理以及它为什么会被忽略2.1 robots.txt 到底是什么robots.txt是放在网站根目录下的一个纯文本文件全称叫“Robots Exclusion Protocol”翻译过来是“机器人排除协议”。它做的事情很简单告诉来访的网络爬虫哪些路径允许抓取哪些路径禁止抓取。一个最小示例User-agent: * Disallow: /admin/ Allow: /public/第一行User-agent: *表示规则对所有爬虫生效Disallow: /admin/表示禁止抓取/admin/路径Allow: /public/表示允许抓取/public/路径。2.2 协议的本质是“君子协定”理解robots.txt的关键在于它是一个声明不是一个技术屏障。服务器收到爬虫请求时并不会因为robots.txt里写了Disallow就直接拒绝请求。它只是把这份文件返回给爬虫然后由爬虫决定是否遵守。从协议设计上看它依赖爬虫开发者的自律和善意。遇到负责任的搜索引擎爬虫比如 Googlebot、Bingbot它们会定期读取robots.txt并遵守规则。但遇到不遵守规则的爬虫服务器端没有任何内置机制可以强制拦截。这就是为什么很多人觉得“明明配置了Disallow却没用”的原因。你并没有配置错而是把希望寄托在了一个没有强制力的协议上。2.3 几种容易被忽略的常见原因问题现象可能原因说明已配置 Disallow 但仍然被抓取爬虫不读取或忽略 robots.txt协议本身无强制力需要服务器层拦截规则写法不完整路径或 UA 不匹配robots.txt 规则是前缀匹配写法要检查命中缓存旧规则爬虫长时间未重新读取 robots.txt新规则对已经缓存旧规则的爬虫不立即生效UA 匹配错误配置的 User-agent 与实际爬虫 UA 不一致需要先确认真实 UA正确顺序是先确认爬虫真实 UA 和来源再配置robots.txt最后在服务器层做强制拦截。3. 第一步永远是确认身份它是真的 Amazonbot 吗3.1 不要只看 UA 字符串UA 字符串是可以随意伪造的。从爬虫日志分析的经验来看很多恶意工具会把 UA 伪装成 Googlebot 或 Amazonbot目的是掩盖真实身份。所以判断标准不能只停留在“日志里的 UA 写着 Amazonbot”而要做反向验证。常见的 Amazonbot UA 长这样Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Amazonbot/0.1具体格式可能随时间调整所以更可靠的方法是多维度验证。3.2 通过反向 DNS 验证来源大型搜索引擎和云服务商的爬虫通常会给出口 IP 配置 PTR 记录也就是反向 DNS 名称。验证思路是从访问日志里取出请求 IP对这个 IP 做反向解析看解析出来的主机名是否包含amazonbot、amazonaws等关键词再查一下这个 IP 是否属于亚马逊的 ASN。在 Linux 服务器上可以执行dig -x 203.0.113.10 short如果解析结果中出现类似amazonbot.amazon.com这样的主机名那么这个请求大概率来自亚马逊官方爬虫。如果没有解析结果或主机名对不上则需要怀疑 UA 是否被伪造。从日志里批量验证可以写一段简单的 shell 命令把日志中 Amazonbot UA 对应的 IP 提取出来再做反查grep Amazonbot /var/log/nginx/access.log | awk {print $1} | sort -u | while read ip; do echo IP: $ip dig -x $ip short done这段命令会把日志里带有Amazonbot字符串的请求的 IP 全部提取出来再分别做反向 DNS 解析。人工核对解析结果就能快速区分真实性。3.3 通过 IP 归属确认如果反向解析不可用还可以用whois查询 IP 归属whois 203.0.113.10 | grep -i OrgName\|NetName假设查询结果显示这个 IP 的注册机构是 Amazon 相关组织那么基本可以确认爬虫来源。如果查询结果显示 IP 属于某个云主机、住宅网络或未知机房则说明 UA 很可能是伪造的需要按恶意扫描来处理。判断要点总结验证维度真 Amazonbot 特征伪 Amazonbot 特征User-Agent包含 Amazonbot 标识可能只有 Chrome 或 Python 请求库标识反向 DNS主机名含 amazon 相关字段无 PTR 或主机名无关IP 归属Amazon 云服务商 IP 段普通机房、住宅 IP 或其他云厂商请求行为高频请求路径为公开页面路径随机可能存在注入探测特征如果 IP 归属没问题、反查也对得上就说明确实是 Amazonbot接下来要处理的是“如何限制它的频率和范围”如果反查对不上就要按恶意爬虫来处理处理方式会更激进一些。4. 分析请求特征把防御规则做细4.1 请求频率与路径分布确认爬虫身份之后下一步是分析它的请求特征。观察点主要有三个频率、路径、UA 稳定性。频率Amazonbot 的采集频率通常远高于普通用户。观察日志里同一 IP 每分钟的请求数如果持续超过阈值说明爬虫可能已经进入“无节制抓取”状态。路径如果请求集中在/robots.txt、/sitemap.xml、文章详情页这类低动态路径说明是“正经采集”如果请求覆盖了登录页、API 接口、上传接口就需要注意。UA 稳定性同一个 IP 是否同时使用多个 UA 交替请求如果是爬虫可能使用了代理池或自动换 UA 策略。4.2 如何高效统计日志可以使用一条 awk 命令快速统计来源 IP 的请求量awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20如果日志格式不是默认的 Nginx 格式需要把$1调整为真实 IP 所在列。执行后输出的第一列是请求次数第二列是 IP 地址通过这个排行能快速找出“异常高频 IP”。再叠加 UA 过滤grep -i Amazonbot /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -rn | head -10这一步能单独列出 Amazonbot 的 IP 和请求量后续封禁时就有明确目标。4.3 CDN 与回源 IP 的注意点如果站点使用了 CDN日志分析时一定要注意访问日志里记录的可能是 CDN 节点 IP而不是真实客户端 IP。此时需要确认 Web 服务器收到的X-Forwarded-For或CDN-Source-IP请求头是否被正确记录。正确的分析方式是先看 CDN 访问日志或原始请求头再提取真实 IP。如果直接在源站日志里拿最后一跳的 IP 做封禁很可能会封到 CDN 节点上导致正常用户也无法访问。5. 多层防御策略从声明到强制对爬虫的防御不应该只依赖某一层。推荐的顺序是先声明再过滤再封禁最后监控。5.1 第一层完善 robots.txt 声明虽然robots.txt不能强制拦截但它是必要的“声明”。如果未来因为数据抓取产生纠纷这份声明可以作为依据。在robots.txt中针对 Amazonbot 单独配置User-agent: Amazonbot Disallow: / Allow: /about/ User-agent: * Allow: / Disallow: /admin/ Disallow: /api/private/这里做了三件事对 Amazonbot 声明禁止全站抓取只放行/about/对其他爬虫保持正常允许对涉及隐私的路径单独禁止。5.2 第二层Web 服务器强制过滤robots.txt不管用就必须在 Web 服务器层强制拒绝。下面是 Nginx 的配置示例。假设你已经确认需要拦截 Amazonbot 的请求可以在server块里加入# 文件路径/etc/nginx/conf.d/block-amazonbot.conf map $http_user_agent $block_amazonbot { default 0; ~*Amazonbot 1; ~*amazonbot 1; } server { listen 80; server_name example.com; if ($block_amazonbot) { return 403; } }需要注意的是map指令需要放在http上下文。最省事的做法是把map块写在nginx.conf的http {}内然后在server块里引用变量。如果希望封禁时返回 403 而不是直接断开可以保留return 403方便在前端确认规则生效。Apache 的配置比较直接在虚拟主机配置里添加# 文件路径/etc/apache2/sites-available/example.com.conf IfModule mod_rewrite.c RewriteEngine On RewriteCond %{HTTP_USER_AGENT} Amazonbot [NC] RewriteRule ^ - [F,L] /IfModule[F]会返回 403 Forbidden[L]表示最后一条规则。这样 Apache 就会直接拒绝所有 UA 中包含 Amazonbot 的请求。5.3 第三层防火墙层封禁 IP如果通过日志找到了高频请求的 IP可以直接在防火墙层封禁。这种方式对资源的消耗最小因为请求在到达 Web 服务器之前就被拒绝。使用 iptablesiptables -A INPUT -s 203.0.113.10 -j DROP使用 firewalldfirewall-cmd --permanent --add-rich-rulerule familyipv4 source address203.0.113.10 drop firewall-cmd --reload但手动封禁 IP 的问题在于无法应对 IP 段不断变化的情况。大型爬虫的出口 IP 往往很多手动添加很难持续。更合理的做法是结合 fail2ban用规则动态封禁。5.4 第四层WAF/CDN 托管规则如果你的网站用了 Cloudflare 或其他云 WAF可以在 WAF 层面创建规则。这里以通用的“拦截 User-Agent 包含 Amazonbot 且命中频率阈值”为逻辑示例不再绑定具体厂商规则条件 - User-Agent 包含 Amazonbot - 且相同 IP 在 5 分钟内请求次数超过 100 次 执行动作 - 返回 403 - 触发 IP 封禁周期 24 小时这类规则在 WAF 层生效可以保源码站 IP 不暴露也不需要维护服务器防火墙规则。5.5 第五层代价较高的兜底方案如果爬虫已经演化到“换 UA、换 IP、模拟浏览器行为”的程度前面几层可能都失效。这时还能做的措施包括对核心接口强制要求登录或携带 Token对高频访问触发验证码通过 JS 挑战或 Cookie 校验区分真人用户和脚本客户端在数据库中记录来源 IP 和 UA建立访问行为分析模型。这些方案的优点是防得住大多数爬虫缺点是会影响正常用户使用也会增加开发成本。所以一般建议先做前四层确认仍然存在严重爬虫问题时再考虑第五层。6. 完整示例从日志识别到自动封禁6.1 示例场景说明假设你有一台 Nginx 服务器最近发现 Amazonbot 高频请求日志但robots.txt无法约束它。现在目标是自动从日志中识别异常 IP自动封禁这些 IP可观察封禁记录防止误伤。6.2 过滤 UA 的 Nginx 配置创建/etc/nginx/conf.d/block-amazonbot.conf内容如下map $http_user_agent $is_amazonbot { default 0; ~*Amazonbot 1; } limit_req_zone $binary_remote_addr zoneamazonbot_limit:10m rate5r/m;然后在需要保护的server块中添加server { server_name example.com; if ($is_amazonbot) { return 403; } location / { limit_req zoneamazonbot_limit burst10 nodelay; proxy_pass http://127.0.0.1:8080; } }这里同时做了两件事对所有 UA 包含 Amazonbot 的请求返回 403对所有来源 IP 做了 5 分钟 5 次请求的限速配置即使 UA 被修改了高频请求也会被限流。需要注意limit_req_zone同样要放在http上下文。6.3 使用 fail2ban 自动封禁 IP如果偏好在系统防火墙层封禁可以用 fail2ban。先创建过滤器规则# 文件路径/etc/fail2ban/filter.d/amazonbot.conf [Definition] failregex ^HOST .* .*Amazonbot.* ignoreregex 再创建监狱配置# 文件路径/etc/fail2ban/jail.d/amazonbot.local [amazonbot] enabled true port http,https filter amazonbot logpath /var/log/nginx/access.log maxretry 5 findtime 300 bantime 86400上面配置的含义是5 分钟内如果同一个 IP 有 5 次命中 Amazonbot UA 的请求就封禁 86400 秒也就是 24 小时。配置完成后重启 fail2ban 并查看状态systemctl restart fail2ban fail2ban-client status amazonbot如果日志路径或服务器类型不同需要修改logpath比如改成/var/log/nginx/access.log或error.log。fail2ban 的核心价值是“自动识别 自动封禁 自动解封”对周期性出现的爬虫很有效。6.4 定期统计和告警脚本封禁做好之后还需要持续观察。可以写一段定时脚本把当天 Amazonbot 请求量发到日志或通知系统#!/bin/bash # 文件路径/usr/local/bin/check_amazonbot.sh TODAY$(date %d/%b/%Y) COUNT$(grep $TODAY /var/log/nginx/access.log | grep -c Amazonbot) echo $(date) Amazonbot requests today: $COUNT /var/log/amazonbot_monitor.log通过 cron 每天执行一次0 8 * * * /usr/local/bin/check_amazonbot.sh这样每天早上都能得到一个统计值如果请求量突然飙升说明封禁规则可能失效了或者爬虫换了 UA需要重新分析。7. 运行结果与效果验证7.1 如何判断规则已经生效配置完成后不要直接撤要先验证。最简单的验证方式是直接模拟请求curl -I -A Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 Amazonbot/0.1 https://example.com/如果 Nginx 配置生效返回结果应该是403 Forbidden。如果返回200 OK需要检查map块是否放在了http上下文server块里是否真的引用了$is_amazonbot是否配置了 CDN 缓存导致请求没有到达源站是否需要nginx -t检查语法后重新加载配置。7.2 查看日志确认拦截情况执行grep Amazonbot /var/log/nginx/access.log | tail -20如果请求仍在出现但状态码是 403说明拦截生效。如果状态码是 200说明请求仍然正常进入了后端。也可以过滤状态码确认grep 403 /var/log/nginx/access.log | grep Amazonbot | tail -207.3 验证 CDN 层是否生效如果规则配置在 CDN/WAF 上验证方式是在本地加一个自定义请求头或特殊 UA 请求测试。CDN 返回 403 时响应头通常会带有 WAF 的标识。注意不要对线上正式环境随意测试建议先用测试域名或灰度域名验证。7.4 误伤排查封禁规则生效后还有一件重要的事检查正常流量是否受影响。可以对比封禁前后几小时内的整体访问量如果出现整体下降说明配置可能过于激进。特别是使用 UA 关键词过滤时一定要确认没有误伤搜索引擎的正常收录。比如 Googlebot 的 UA 里不会包含 Amazonbot所以正常情况下不会误伤但要小心使用“泛关键词”的情况比如过滤器写了bot就可能误伤很多正当爬虫。8. 常见问题与排查思路问题现象可能原因排查方式解决方案配置了 robots.txt 但仍然被抓取robots.txt 没有强制力在服务器层检查请求来源和 UA用 Nginx/Apache/防火墙层拦截封禁 UA 后请求仍然返回 200规则未生效或语法错误执行nginx -t查看错误日志修正配置并重新加载请求来自 CDN IP封禁后误伤整个 CDN源站看到的 IP 是 CDN 节点检查X-Forwarded-For字段使用 CDN 上的规则而不是源站防火墙Amazonbot 频繁更换 UA爬虫做了 UA 伪装统计请求频率和行为特征使用限速规则不只依赖 UA 匹配fail2ban 没有封禁任何 IP日志正则不匹配手动执行 fail2ban-regex 测试调整 failregex 规则封禁后正常用户访问变慢误封了某个公网出口 IP查看封禁列表和请求日志缩短封禁时间增加白名单源站在中国大陆CDN 无法覆盖网络链路问题检查访问日志来源 IP在源站防火墙层增加限流规则真实环境中的爬虫策略变化很快排查时最重要的原则是每一步都要有日志作为依据不要凭猜想去封 IP。9. 最佳实践与工程建议9.1 日志保留策略没有日志就无法分析爬虫行为。建议在服务器上保留至少 7 天的访问日志如果条件允许保留 30 天。可以使用logrotate定期切分和压缩/var/log/nginx/access.log { daily rotate 7 compress delaycompress missingok notifempty create 640 www-data adm }这个配置会每天切分一次日志保留 7 份历史压缩文件。这是排查爬虫问题时最基础也是最重要的一步。9.2 维护“可控爬虫”和“恶意爬虫”两个名单不同爬虫的处理方式不一样。像 Googlebot、Bingbot 这类有规律、有官方文档且通常遵守 robots.txt 的爬虫一般建议放行因为它们会给网站带来搜索流量。但 Amazonbot 这类以数据采集为目标的爬虫即便来自正规公司也需要根据自身业务需求决定是否限制。建议把爬虫分成三类分类示例处理方式有益爬虫Googlebot、Bingbot放行并配置 robots.txt中性爬虫普通 SEO 检测工具、偶尔抓取的爬虫观察频率适当限速有害爬虫高频采集、无视 robots.txt、扫描漏洞的脚本UA 过滤、IP 封禁、防火墙限制把名单写进配置或文档后续维护时会非常方便。9.3 从 UA 封禁过渡到行为封禁依赖 UA 的封禁有一个明显缺点UA 可以伪造。大型爬虫如果决定规避可以很容易地在请求里去掉 UA 标识。所以更可靠的方案是加上“行为封禁”同一 IP 相同时间窗口内请求次数超过阈值同一 IP 在短时间内请求大量不存在的路径请求频率曲线与真实用户明显不一致。Nginx 的limit_req、fail2ban 的频率统计、WAF 的速率规则都能实现行为层面的控制。建议把这几层组合使用而不是只依赖单一条件。9.4 避免误封的几条红线不要封禁 CDN 节点 IP应该封禁真实客户端 IP不要对全站启用过于严格的 UA 过滤至少要保留搜索引擎爬虫和白名单 IP不要对动态接口做无限速的封禁先观察 24 小时再决定是否长期封锁封禁操作要有回滚预案误封后能快速解封。9.5 考虑资源隔离如果站点规模较大建议把静态资源和动态接口分开部署。爬虫通常对静态资源更感兴趣分开部署后即使被爬虫抓取也不会直接影响数据库和应用服务。另外如果确实需要向 AI 训练类爬虫开放部分内容可以把数据量大的接口单独放在一个子域名并提供独立的速率限制降低对核心业务的影响。10. 总结与后续方向这篇文章解决的核心问题就是“爬虫无视 robots.txt 时站长能做什么”。起点是对robots.txt的清醒认知它只是声明规范不是技术拦截。面对 Amazonbot 这类爬虫正确做法是把防御重心转移到服务器层和网络层。先通过反向 DNS 和 IP 归属确认爬虫身份再通过 UA 过滤、限速配置、IP 封禁逐层收紧最后用日志和监控验证效果。对一个网站运营者来说最值得养成的习惯就是定期分析访问日志。日志里藏着大量信息哪些路径被高频访问、哪些 IP 行为异常、哪些接口被恶意扫描。只要把这件基础工作做扎实遇到类似爬虫问题时就不会慌。后续如果你想把这件事做得更自动化可以继续研究这几个方向用 fail2ban 或类似工具建立动态封禁规则、在 WAF 上配置频率控速策略、建立基于访问行为的异常检测告警。技术本身不复杂难的是把“分析、封禁、验证、复盘”这套流程固化到日常运维里。