最近不少站长在日志里发现一个高频爬虫叫 Amazonbot也就是亚马逊官方维护的网络爬虫。它名义上是来抓取公开网页的但实际跑起来经常无视 robots.txt 里的 Disallow 规则同一时间从多个 IP 发起请求把低价值页面、翻页参数页、历史版本页全部扫一遍。轻则日志快速膨胀重则 CPU 和带宽被打满动态网站甚至直接卡到无法响应。如果你也遇到这种情况先不要急着把整个 AWS IP 段封掉。这篇文章我会按实际排查顺序拆一遍先确认日志里的访客到底是不是 Amazonbot再检查 robots.txt 是否配置到位接着看 Nginx、Apache、Cloudflare 这类服务器和 WAF 层怎么拦截和限速最后补充几个容易误伤的案例和验证标准。这个主题适合个人站站长、运维工程师以及部署了动态站点后发现请求量异常的人。最值得关注的一个判断是不要把全部希望放在 robots.txt 上它只是君子协议对不守规矩的爬虫几乎没有强制约束力。1. 先弄清楚 Amazonbot 到底是来干什么的1.1 它不是搜索引擎爬虫也不会带来流量Amazonbot 是亚马逊自己维护的网络爬虫UA 注释里通常带一个指向 developer.amazon.com 的链接。它的目的一般是拉取网页内容用于商品信息、比价、知识库构建等场景。注意它和 Googlebot、Bingbot 不一样它不负责网页收录也不会给你的站点带来搜索流量。所以从流量收益角度看屏蔽它一般不直接影响主流搜索引擎收录。很多人的第一反应是“亚马逊这么大的公司爬虫应该很规范”但实测下来规范是官方文档里的描述实际行为要另说。我第一次在日志里看到它的 UA 时也差点把它当普通浏览器。因为 UA 字符串里带了 Mozilla/5.0 前缀容易误导。实际上它只是借用了浏览器兼容前缀和真实浏览器不是一回事。这里有个快速区分方法Googlebot 会带来网页收录和搜索流量封了会影响 SEO。Bingbot 类似是搜索引擎爬虫。Amazonbot 主要拉取页面内容供亚马逊产品使用不构成搜索流量来源。如果站点内容和商品、比价、购物场景无关Amazonbot 抓取的价值很低但消耗的资源却可能很高。所以处理优先级上Amazonbot 往往要比搜索引擎爬虫更靠前。1.2 “激进抓取”到底激进在哪里从日志上看Amazonbot 的行为和普通爬虫有明显差异。普通爬虫一般会先抓 robots.txt再按顺序抓取。Amazonbot 在部分站点上的表现是请求频率高短时间对几十个页面发起请求会对带排序参数、筛选参数、翻页参数的 URL 也发起请求单次任务里从多个 IP 出现看起来像分布式抓取即使 robots.txt 已经声明 Disallow仍然继续请求对后台入口、临时文件、备份文件这类敏感路径也可能探测如果站点是纯静态页面影响可能只是流量账单变大。如果是 WordPress、Typecho或者 Node、Python 写的动态站点每次请求都会触发数据库查询、模板渲染和缓存写入。请求量一大CPU 和内存很容易被打满。我建议先做个影响评估如果每天只是几百次请求可能只是日志里难看如果每分钟就有几百次请求就要立刻处理。可以用htop看 CPU用free -h看内存用iftop看实时带宽。先把问题量化再决定用什么级别的拦截。2. 别凭感觉判断第一步永远是翻日志2.1 从访问日志里把 Amazonbot 单独筛出来不管是 Nginx 还是 Apache访问日志都会记录 User-Agent。先用命令按关键词筛选grep -i amazonbot /var/log/nginx/access.log | tail -n 50如果日志里有大量结果再按来源 IP 统计请求量grep -i amazonbot /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -rn | head -50第一条命令能让你看到它在抓哪些 URL。第二条命令能看出来源 IP 和请求量分布。先看 URL再看 IP最后看时间分布这个顺序不要颠倒。从 URL 上可以判断被爬虫盯上的内容类型。如果抓的全是首页和文章页说明可能是正常内容采集如果抓的是带参数的结果页或后台登录路径就要更重视。后者不仅是资源消耗问题还可能带有目录探测性质。如果你的站点没有单独的 access log需要先确认 Web 服务器日志路径。Nginx 默认一般在/var/log/nginx/access.logApache 在/var/log/apache2/access.log或/var/log/httpd/access_log。如果没开启日志先把日志打开再处理爬虫问题。没有日志就谈拦截很容易误伤。2.2 确认来源 IP 是否属于亚马逊只靠 UA 还不够因为有些爬虫会伪装 UA。为了确认可以取几个来源 IP 做反向查询whois 3.5.140.2也可以用dig -x做 PTR 反查。判断标准是IP 属于 AWS 的地址段并且 PTR 记录里包含 amazon 相关的域名片段。Amazon 在 UA 注释页面上说明过如何验证 Amazonbot 的真实来源实测时先用官方说明交叉验证一下更稳妥。这里有个容易被忽略的点Amazonbot 的 IP 通常来自 AWS但 AWS IP 地址段范围非常大。不能因为 IP 属于 AWS 就直接封整个地址段否则会把大量正常访客一并挡在外面。后面会详细说为什么。2.3 判断影响级别是噪声还是事故同样出现 amazonbot 关键词影响级别可能完全不同。低影响每天几十到几百次请求只在日志里能看到服务器负载没有明显变化。可以先观察不必立刻封禁。中影响请求量达到每小时几百次动态页面响应变慢或者带宽占用明显上升。建议先限速再决定是否 403。高影响CPU 接近打满数据库连接数耗尽正常用户打不开页面。这时候不要犹豫直接先在服务器或 WAF 层拦截再慢慢看日志优化规则。不要一上来就写一组复杂规则。先把影响级别定下来才知道该花多少精力处理。3. 把 robots.txt 配置到位但别只依赖它3.1 标准配置写法robots.txt 的配置不复杂。如果想彻底禁止 Amazonbot可以在根目录的 robots.txt 里加User-agent: Amazonbot Disallow: /如果想允许它抓一部分内容同时禁止敏感路径User-agent: Amazonbot Allow: /articles/ Disallow: /private/ Disallow: /search? Disallow: /admin配置完成后可以用 curl 模拟请求确认 robots.txt 本身能正常访问curl -A Mozilla/5.0 (compatible; Amazonbot/0.1; https://developer.amazon.com/support/amazonbot) https://你的域名/robots.txt注意curl 验证的是文件是否能访问不是验证爬虫是否遵守。要确认爬虫是否遵守还得继续看访问日志里 robots.txt 之后的页面请求情况。如果 robots.txt 已经 Disallow但日志里仍然有大量页面抓取说明对方没有按声明执行。3.2 为什么配置了 Disallow 还是会被抓robots.txt 本质上是一种声明。它相当于网站上贴了一张“请勿入内”的告示对守规矩的爬虫有效对不守规矩的爬虫就是一张废纸。Amazonbot 在官方文档里说会遵守 robots.txt但实际部署中仍然有大量站长反馈它出现高并发抓取、忽略 Disallow 的情况。这个问题的可能原因包括爬虫任务队列里的 URL 在 robots.txt 更新前就已经生成多台抓取机器共享任务队列部分机器没有同步最新的 robots.txt请求经过 CDN 或反向代理robots.txt 被缓存导致爬虫拿到旧版本不同平台对 robots.txt 解释不同某些 Allow 和 Disallow 的优先级处理不一致不要纠结具体原因关键是结论robots.txt 要做但它只是第一道防线。如果请求已经对服务器造成压力必须继续到服务器或 WAF 层处理。3.3 Crawl-delay 不要当作可靠手段有人会在 robots.txt 里加Crawl-delay: 10希望让爬虫每 10 秒只抓一次。这个指令在 robots.txt 标准里并不是所有爬虫都支持。很多主流爬虫已经不支持 Crawl-delayAmazonbot 是否支持也需要实测。如果你发现加上之后日志里的请求频率没有变化就说明它不认这个指令。这时候不要继续调大数字直接转到服务器层做限速会更有效。注意不要一上来就封锁 AWS 的整个地址段先按 UA 和具体 IP 处理观察一段时间再考虑是否升级。4. 服务器层拦截和限速实际操作才有效4.1 Nginx 按 UA 拦截如果确认 Amazonbot 的 UA 是固定的可以在 Nginx 配置里直接拦截if ($http_user_agent ~* Amazonbot) { return 403; }这个配置放在 server 块里就可以。实际使用时要注意 Nginx 的 if 指令有使用限制但用于按 UA 返回 403 是稳定的不需要放在 location 里。配置完先测试语法再重载nginx -t systemctl reload nginx重载之后再用模拟请求验证curl -I -A Mozilla/5.0 (compatible; Amazonbot/0.1; https://developer.amazon.com/support/amazonbot) https://你的域名/如果返回 403说明拦截生效。之后要回日志里确认真实 Amazonbot 的请求是否也在快速回落。4.2 Apache 按 UA 拒绝Apache 下可以用mod_rewriteRewriteEngine On RewriteCond %{HTTP_USER_AGENT} Amazonbot [NC] RewriteRule .* - [F]也可以启用mod_setenvif设置环境变量再拒绝。两种方式实际效果差别不大按你习惯选。这种按 UA 拦截的方式优点是配置简单、立即生效。缺点是如果 Amazonbot 以后修改 UA规则就会失效。目前大概率它的 UA 是固定的但为了稳妥UA 拦截规则要和 IP 分析、频率限制搭配使用。4.3 限速而不是一刀切有些场景不一定想彻底拒绝 Amazonbot。比如你的业务可能需要亚马逊的外部链接预览正常或者你还在判断它到底会不会带来转化。这时候可以限速limit_req_zone $http_user_agent zoneamazonbot:10m rate1r/m;然后在需要限速的 location 里引用location / { limit_req zoneamazonbot burst5; }这段配置的意思是按 User-Agent 维度每分钟只允许 1 个请求突发最多 5 个。实际效果是抓取可以发生但不会持续打爆资源。限速比直接 403 更温和也适合边界不明确的场景。我一般建议先限速观察几天日志。如果请求量还是高再升级为 403。限速生效后访问日志里会出现大量 503 响应这是 Nginx 在拒绝超过限制的请求不要误以为服务出故障。4.4 动态页面和静态资源要分开处理如果你的站点有大量动态页面比如搜索、分类、标签页建议在 Nginx 或 WAF 层针对这些动态路径单独做更严格的限制。同一个 IP 爬一遍静态页面压力未必大但如果它反复请求动态搜索 URLCPU 会明显上升。可以对静态资源设置长缓存location ~* \.(js|css|png|jpg|gif|svg|webp)$ { expires 30d; access_log off; }加上缓存后即使爬虫一直在请求静态文件也不会每次都打到后端。对动态路径可以单独限制并发和速率。把两类请求分开处理能明显降低爬虫对源站的影响。5. WAF、Cloudflare 与 AWS 地址段的取舍5.1 Cloudflare 防火墙规则怎么加如果站点套了 Cloudflare可以加一条防火墙规则规则名称Block Amazonbot by UA匹配条件User Agent contains amazonbot操作Block 或 Managed Challenge在 WAF 层拦截的好处是请求不会到达源服务器能有效降低源站压力。缺点是只靠一条规则不够因为如果源站 IP 被直接扫描WAF 也拦不到。所以 WAF 规则要和源站访问控制、服务器层限制一起用。如果你的源站只允许 Cloudflare IP 访问可以在服务器层限制 80 和 443 端口只接受 Cloudflare 地址段。但这不是所有场景都适合需要结合你的部署方式判断。个人站可以先把 Cloudflare 的 Block 规则打开观察源站负载和日志变化。5.2 为什么不要直接封 AWS IP 段Amazonbot 的 IP 基本来自 AWS。但 AWS 的 IP 地址段范围非常大而且很多正常用户、第三方 API 调用也都来自这些地址段。直接封整个 AWS IP 段误伤概率极高。如果你在 Cloudflare 里封掉 AWS 的 /0 网段等于告诉全球所有使用 AWS 云服务的访客“你们进不来”。如果你的站是开发者社区、技术博客或者用户群里恰好有大量云服务使用者误伤会非常明显。更稳妥的做法是从日志里找出确实在发起高频抓取的单个 IP 或 /24 网段单独封禁。比如某个 IP 一小时内请求上千次就封这个 IP。如果多个 IP 连续出现再扩展到一个较小的网段。封完之后继续观察不要一口气写一堆自动化封禁逻辑除非你的运维能力已经足够支撑误伤处理。5.3 更进一步请求指纹和行为分析如果 Amazonbot 以后改了 UA或者开始用更隐蔽的方式抓取单纯靠 UA 就不够了。这时候可以看几个特征请求深度正常用户一般只看少数页面爬虫会沿着 URL 结构大量遍历页面相关性普通用户访问路径集中在内容页爬虫可能连登录页、错误页、管理路径都请求Cookie 和 JavaScript 执行如果站点启用了 JS 验证没有执行能力的爬虫会被过滤这些手段执行成本更高普通个人站不一定需要一开始就上。先做到 UA 拦截和限速再观察日志。如果问题持续出现再引入请求指纹和行为分析。6. 容易误伤的情况以及完整的排查清单6.1 容易误伤的三种情况第一种是伪装成 Amazonbot 的其他爬虫。有些安全扫描工具或抓取工具会故意使用常见爬虫 UA你以为在拦 Amazonbot实际上把扫描器放过去了。判断方式看行为是否请求wp-login.php、.git/config、.env这类路径。如果出现这些路径说明不是普通内容抓取需要按更严格的方式处理。第二种是亚马逊相关业务真实依赖。如果你的内容需要被亚马逊的链接预览、广告投放页面、商品对比页面引用全封可能会影响外部展示效果。这种情况我建议先限速不彻底断掉。等确认没有业务影响后再决定是否升级为 403。第三种是只封 UA 却忘记处理 IP。很多爬虫支持自定义 UA被 403 后换一个 UA 继续抓。所以要关注多次 403 后的新 UA 模式再结合 IP 段做二次判断。日志分析不是一次性的前两周要定期抽查。6.2 完整排查顺序按这个顺序走基本不会漏看现象是日志膨胀、带宽异常、CPU 升高还是数据库连接被打满看访问日志按 amazonbot 关键词筛选确认请求量看 URL 类型确认是内容页还是动态参数页看 IP 归属反查 AWS 地址段确认来源看 robots.txt是否已经配置 Disallow是否被遵守先加限速再升级为 403验证观察 24 小时日志确认请求量下降同时确认没有误伤正常用户长期维护把 UA、IP 段、请求频率写入监控出现波动时能及时知道验证的标准不是“配置完不报错”而是每天请求量是否下降、服务器负载是否回落、正常用户访问是否无感知。如果只看到日志里 403 变多但错误页面请求本身还在打后端说明防护层放得太靠后了还要继续往前移。判断是否误伤不能只看页面能打开还要看正常用户的关键路径比如登录、搜索、下单是否受影响。这几个路径一旦被误拦截损失比爬虫带来的压力大得多。6.3 长期维护建议如果 Amazonbot 不断换 IP 但 UA 固定UA 规则就很有效。如果它以后换 UA你需要从 AWS IP 段、请求频率、页面内容模式综合判断。个人站不用过度自动化先保证日志干净、有告警、能快速处置就够了。有条件的话把访问日志接入简单的监控告警比如请求量突增时收到通知。不需要搭复杂平台一个定时脚本统计日志就够。关键是出了问题能第一时间知道而不是等访问者投诉时才去翻日志。最后说句实践体会处理这种爬虫问题最怕的不是爬虫本身而是看到 UA 就急着写一堆封锁规则。先把日志读明白再把 robots.txt、服务器层、WAF 三层各自的作用理清楚问题基本就能控制住。