最近在 Hacker News 上有一个讨论热度很高的标题Amazonbot 疯狂抓取网站甚至无视 robots.txt 规则。很多站长在帖子下面补充了同样的遭遇——明明已经在 robots.txt 里写了Disallow: /访问日志里却依然出现大量来自 Amazonbot 的请求部分请求还能直接命中后端接口把服务器负载拉得很高。这不是个案。Amazonbot 是亚马逊官方推出的网络爬虫和 Googlebot、Bingbot 一样它也有自己的一套抓取规则。但在实际部署中很多站点发现 robots.txt 对它的约束力并不稳定。本文会从 Amazonbot 到底是什么、robots.txt 为什么会被“无视”开始讲起然后逐步给出可落地的识别方案、拦截方案、日志分析方法和工程建议。无论你是个人站长还是公司后端、运维开发都可以按这篇文章的思路去排查和加固自己的站点。1. 背景与核心概念1.1 Amazonbot 是什么Amazonbot 是亚马逊用于抓取公开网页内容的爬虫程序。它主要服务于亚马逊的商品知识图谱、搜索结果增强、以及部分 AI 相关的数据处理链路。你可以把它理解为“亚马逊版 Googlebot”只不过它的抓取目标和抓取策略跟搜索引擎爬虫并不完全一样。从公开资料来看Amazonbot 的默认 User-Agent 通常包含Amazonbot关键字常见形式类似Mozilla/5.0 (compatible; Amazonbot/0.1; https://developer.amazon.com/support/amazonbot)注意这个 User-Agent 是可以被请求方任意伪造的。也就是说你在日志里看到Amazonbot不一定是真的亚马逊爬虫反过来亚马逊爬虫也可能在部分请求中不走标准的 UA 格式。因此后面我们会强调识别爬虫不能只看 User-Agent 一个字段。1.2 robots.txt 为什么会失效robots.txt 是一个放置于网站根目录的纯文本文件它通过User-agent和Disallow/Allow指令告诉爬虫“哪些路径可以抓哪些路径不可以抓”。它本质上是一个君子协议完全依赖爬虫方自觉遵守。robots.txt 失效通常有几种原因规则配置错误User-agent名称匹配不上或者路径写错导致规则没有覆盖到实际请求。缓存问题爬虫侧缓存了旧的 robots.txtCDN 或浏览器缓存也可能会让更新延迟生效。爬虫不遵守部分爬虫在设计时只实现了“读取 robots.txt”的功能但没有严格限制所有子路径也有的爬虫会忽略Crawl-delay等非强制字段。IP 分散抓取爬虫的出口 IP 数量多、地域分散很难用简单的 IP 黑名单完全封闭。回到 HN 那个帖子的场景用户反馈 Amazonbot“无视”robots.txt很可能是因为 Amazonbot 的抓取策略在某些路径上并不严格参考根域名的 robots.txt也可能是 Amazonbot 使用了不同的 UA 或 IP 段导致站点侧的过滤规则没有命中。1.3 这个问题的普遍影响当一只爬虫无视 robots.txt 且高频抓取时实际影响并不只是“多了一点日志”这么简单服务器资源消耗每次抓取都会产生请求处理、数据库查询、日志写入等开销。爬虫频率一高CPU 和带宽占用会明显上升。用户体验变差如果爬虫请求占满了连接池或应用线程真实用户的访问延迟会跟着上升。业务数据风险如果网站存在未做权限校验的接口爬虫可能抓取到本不该公开的数据例如商品价格、库存、用户头像、评论内容等。统计失真高频爬虫会让 PV/UV 统计、热门文章排行等数据变得不可信。所以处理 Amazonbot 的问题并不是“看它不顺眼”才去拦截而是为了保护站点稳定性、数据安全和统计准确性。下面我们从识别开始逐步搭建一套防护方案。2. 问题现象与影响分析2.1 如何判断自己的网站正在被 Amazonbot 抓取要判断是否被 Amazonbot 抓取最直接的方法是查看 Web 访问日志。以 Nginx 为例默认访问日志路径通常是/var/log/nginx/access.log可以用 grep 快速过滤grep -i Amazonbot /var/log/nginx/access.log | tail -n 50如果日志里出现大量 UA 含Amazonbot的请求就说明爬虫已经来过。进一步看你还可以统计单位时间内的请求量grep -i Amazonbot /var/log/nginx/access.log | awk {print $4} | sort | uniq -c | sort -nr | head -n 20这段命令按日期时间统计 Amazonbot 请求数量能看出它是不是在短时间密集抓取。如果站点前面有 CDN比如 Cloudflare、阿里云 CDN、腾讯云 CDN你需要去 CDN 的日志分析功能里查询。很多 CDN 会隐藏源站真实 IP但访问日志里依然保留请求 UA所以查 UA 依然是最快的方式。2.2 高频抓取给站点带来的实际影响我帮你把这个过程拆开来看。假设一个小型网站部署在 2C4G 的云服务器上后端是 Spring Boot MySQL前面用 Nginx 做反向代理。平时每秒请求量大概在 20 左右服务器负载还算健康。当 Amazonbot 开始高频抓取时可能会出现下面这些现象现象原因负载升高CPU 使用率持续 80% 以上大量请求穿透 Nginx到达应用层MySQL 慢查询增多爬虫会沿着详情页链接递归抓取触发大量 SQL 查询真实用户访问变慢Tomcat 或 PHP-FPM 的线程池被爬虫请求占用日志磁盘占用快速增长高频请求导致 access log 和业务日志膨胀第三方接口费用超支如果页面渲染时调用了地图、短信、AI 等付费 API爬虫也会“帮忙”消耗配额最怕的是爬虫抓取那些不应该被公开的 URL比如带参数的搜索页、导出接口、后台预览链接。即使页面没有直接展示敏感数据高频请求也会对系统产生真实压力。2.3 Amazonbot 与普通搜索爬虫的区别很多站点已经习惯了 Googlebot 和 Bingbot 的抓取节奏因此对 Amazonbot 的“进攻性”感受更明显。它们的区别主要在于抓取目标不同搜索引擎爬虫目标是收录页面建立索引Amazonbot 目标偏向商品信息、开放图谱数据和可被用于构建知识体系的内容。抓取深度不同Amazonbot 对商品详情页、价格页、评论页的抓取深度通常更大甚至会把带参数的筛选页也爬一遍。robots.txt 遵守程度不同Googlebot 和 Bingbot 对 robots.txt 的遵守非常严格而 Amazonbot 在不同时间段的策略存在变化社区里也出现了不少“设置后依然被抓”的反馈。这里并不是说 Amazonbot 一定是恶意爬虫只是在你的站点没有向亚马逊提交抓取需求的情况下它带来的负担和风险远大于收益。因此主动在服务器和 CDN 双层做限制是保护站点资源的合理选择。3. robots.txt 原理与 Amazonbot 协议支持3.1 robots.txt 基础语法回顾先快速回顾一下 robots.txt 的基本写法。文件放在网站根目录比如https://example.com/robots.txt。User-agent: * Disallow: /private/ Disallow: /api/ Allow: /public/含义很简单User-agent: *表示作用于所有爬虫。Disallow表示禁止抓取的路径。Allow表示允许抓取的路径。空行表示一组规则结束。robots.txt 的有效性有几个前提文件必须能从公网直接访问返回200 OK。文件内容必须是纯文本不能是 HTML 页面。规则路径是“前缀匹配”不是“全字匹配”比如/api会匹配/api/user、/api/order。如果部署了 CDN记得让 CDN 放行根目录 robots.txt不要对这类小文件做强制缓存否则爬虫读到旧的规则更新就会延迟。3.2 Amazonbot 使用哪些 User-Agent从现有的访问日志统计来看Amazonbot 常见的 UA 主要有这样的格式Mozilla/5.0 (compatible; Amazonbot/0.1; https://developer.amazon.com/support/amazonbot) Mozilla/5.0 (Linux; Android 5.0; SM-G920P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36 (compatible; Amazonbot/0.1; https://developer.amazon.com/support/amazonbot)也就是说它有时会附带移动端浏览器标识但核心标识仍是Amazonbot/0.1。需要注意的是UA 属于可伪造字段。你在日志里看到Amazonbot可能有三类情况真正的亚马逊爬虫。第三方模仿 Amazonbot UA 的采集程序。搜索了 Amazonbot 关键词的安全扫描器。因此靠 UA 做拦截只是第一道防线属于“便宜但有效”的方案。要对更复杂的伪造做识别需要配合反向 DNS 查询和 IP 库校验。3.3 robots.txt 的局限性与绕过方式robots.txt 的局限性在于它本身不具备强制力。它既不能被服务器强制执行也不能被浏览器或 CDN 强制执行。一个爬虫完全可以忽略它继续抓取只是这样做不符合搜索引擎行业的通行规范。常见的“绕过”或“失效”情况包括robots.txt 中只写了User-agent: *但爬虫实际使用的 UA 不在匹配范围内。网站通过 JS 动态渲染页面爬虫抓到的 HTML 只有空壳于是反复重试不同参数。网站存在大量重复 URL比如排序、筛选、分页链接爬虫会认为这些是新的页面持续抓取。CDN 把 robots.txt 缓存了爬虫抓到的还是旧版本等于你的新规则没生效。理解了这些限制我们就能明白不能单靠 robots.txt 来挡住 Amazonbot必须在服务器、CDN、应用层多处设防。4. 完整拦截方案从入口到应用层4.1 方案总览这里给出一个完整的拦截思路从上到下一共五层robots.txt 声明层明确拒绝 Amazonbot 抓取全站。Web 服务器层Nginx / Apache 按 UA 直接返回 403 或 444。CDN / WAF 层在云厂商控制台配置 Bot 管理规则或者自定义拦截规则。应用层对高频请求做限流和频控。监控层日志分析和告警确认识别是否准确、拦截是否生效。下面逐一展开。4.2 第一层完善 robots.txt 与声明在站点根目录创建或修改robots.txt将以下内容加入文件User-agent: Amazonbot Disallow: / User-agent: * Disallow: /private/ Disallow: /admin/ Disallow: /api/这里做两件事单独给 Amazonbot 设置Disallow: /明确表示不欢迎抓取全站。给所有其他爬虫也划定禁区防止它们顺着路径深入。更新 robots.txt 后可以先用 curl 验证是否能正常读取curl -I https://example.com/robots.txt预期返回HTTP/1.1 200 OK Content-Type: text/plain如果你的 CDN 开启了 robots.txt 缓存记得刷新缓存或设置较短的缓存时间。否则爬虫侧拿到旧规则新配置等于白做。4.3 第二层Nginx 层拦截 AmazonbotNginx 适合在入口层面直接处理爬虫请求。它可以在不经过后端应用的情况下直接返回 403对服务器资源的消耗极小。先看一个基于map的判断方案。在http块中配置http { map $http_user_agent $bad_bot { default 0; ~*Amazonbot 1; ~*ChatGPT-User 1; ~*GPTBot 1; } server { listen 80; server_name example.com; if ($bad_bot) { return 403; } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } }关键点说明map $http_user_agent $bad_bot会根据请求头里的 User-Agent 做正则匹配。~*Amazonbot表示不区分大小写匹配包含Amazonbot的字符串。if ($bad_bot) { return 403; }直接在 Nginx 层返回 403后续不再进入后端。如果你希望更“安静”地处理可以把return 403改成return 444。444 是 Nginx 特有的状态码会直接关闭连接不返回任何响应体很多采集程序会把这解读为目标不可达。if ($bad_bot) { return 444; }需要注意Nginx 的if指令在location里使用时有一些历史问题但用在上面的场景中做简单判断是没问题的。如果你是资深用户更推荐使用ngx_http_geo_module建立 IP 段黑名单或者使用 OpenResty 的 Lua 逻辑做更复杂的判断。4.4 第三层Apache 层拦截配置如果站点跑在 Apache 上可以在.htaccess或 httpd 配置中使用mod_rewrite拦截。RewriteEngine On RewriteCond %{HTTP_USER_AGENT} Amazonbot [NC,OR] RewriteCond %{HTTP_USER_AGENT} GPTBot [NC] RewriteRule ^ - [F,L]这段配置的含义是当请求 UA 中包含Amazonbot或GPTBot时返回 403 状态码。NC表示不区分大小写F表示 ForbiddenL表示停止后续规则。如果希望拦截后返回 404而不是 403也可以写成RewriteRule ^ - [R404,L]具体用 403 还是 404取决于你的偏好。403 更明确容易排查404 能让部分爬虫更快放弃因为它们觉得“路径不存在”。4.5 第四层CDN / WAF 层拦截对于已经接入 CDN 的网站在 CDN 层拦截比在源站拦截更高效因为请求在边缘节点就被挡下了不会回源消耗服务器资源。常见操作路径如下登录 CDN 控制台找到“访问控制”或“Bot 管理”。新建一条规则匹配字段选择User-Agent。匹配方式选择“包含”值填写Amazonbot。执行动作选择“拦截”或者“返回指定页面”。以 Cloudflare 为例可以在 WAF 自定义规则中写(http.user_agent contains Amazonbot)动作设置为Block。如果是阿里云 CDN 或腾讯云 CDN通常也支持配置 Referer 防盗链、UA 黑白名单、IP 黑白名单。你可以用 UA 黑名单拦截 Amazonbot也可以用 IP 黑名单拦截后续确认的爬虫 IP 段。CDN 层还有一个好处你可以针对某个路径单独拦截比如只拦截/?s搜索页、/product/商品页避免误伤正常用户访问首页。4.6 第五层应用层速率限制即使前面几层都做了依然可能出现漏网之鱼。比如爬虫伪装成普通浏览器 UA或者通过代理池轮换 IP。此时应用层限流是关键兜底。以 Java Spring Boot 为例可以基于拦截器做一个简单的 IP 路径频率限制。这里只给出一个思路性质的代码示例// 文件路径src/main/java/com/example/demo/config/RateLimitInterceptor.java Component public class RateLimitInterceptor implements HandlerInterceptor { private final MapString, DequeLong requestRecords new ConcurrentHashMap(); private static final int MAX_REQUESTS 60; private static final long WINDOW_MILLIS 60_000L; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String clientIp getClientIp(request); long now System.currentTimeMillis(); DequeLong records requestRecords.computeIfAbsent(clientIp, k - new ArrayDeque()); synchronized (records) { while (!records.isEmpty() now - records.peekFirst() WINDOW_MILLIS) { records.pollFirst(); } if (records.size() MAX_REQUESTS) { response.setStatus(429); response.getWriter().write(Too Many Requests); return false; } records.addLast(now); } return true; } private String getClientIp(HttpServletRequest request) { String xff request.getHeader(X-Forwarded-For); if (xff ! null !xff.isBlank()) { return xff.split(,)[0].trim(); } return request.getRemoteAddr(); } }使用限流方案时要注意几个工程细节单机内存限流在集群环境下不准确需要引入 Redis 做分布式计数。限流要区分正常用户和爬虫尽量只限制高频特征避免误伤。返回 429 后可以在响应头中加入Retry-After让遵守协议的客户端延迟重试。5. 日志分析与监控识别真实抓取行为5.1 从访问日志中提取 Amazonbot 请求在完成拦截之前先要把“敌人”看清楚。对于 Nginx 用户你可以统计一段时间内的 Amazonbot 请求密度awk {print $1, $4, $6, $7} /var/log/nginx/access.log | grep -i Amazonbot | head -n 20输出示例192.0.2.10 [18/Oct/2025:10:25:01 0000] GET /product/a 192.0.2.11 [18/Oct/2025:10:25:03 0000] GET /product/b 192.0.2.10 [18/Oct/2025:10:25:05 0000] GET /product/a?page2通过这个结果你可以看到它是不是在递归翻页、是不是集中抓取某个目录、来源 IP 分布如何。5.2 反查 DNS 确认爬虫身份由于 UA 可以伪造更严谨的验证方法是反查 IP 的 PTR 记录。亚马逊官方爬虫通常有对应的反向 DNS 域名例如*.amazonbot.amazon之类的后缀但这类域名会随地区和服务调整。在 Linux 服务器上可以使用dig或nslookup反查dig -x 192.0.2.10 short如果反查结果中能看到amazon相关域名再结合 UA 包含Amazonbot基本可以确认是官方爬虫。如果反查结果是无意义的云主机 IP例如某个 VPS 服务商的动态 IP而 UA 又伪装成Amazonbot那大概率不是亚马逊官方行为可能是第三方模拟。5.3 使用 Python 快速统计抓取频率如果日志文件较大用 Shell 命令不够灵活可以写一个简单的 Python 脚本来统计。# 文件路径analyze_amazonbot.py import re from collections import Counter from datetime import datetime log_file /var/log/nginx/access.log bot_pattern re.compile(rAmazonbot, re.IGNORECASE) ip_counter Counter() time_counter Counter() url_counter Counter() with open(log_file, r, errorsignore) as f: for line in f: if bot_pattern.search(line): parts line.split() if len(parts) 7: continue ip parts[0] time_str parts[3].strip([]) url parts[6] ip_counter[ip] 1 time_counter[time_str] 1 url_counter[url] 1 print( Top 10 IP ) for ip, cnt in ip_counter.most_common(10): print(f{ip}: {cnt}) print(\n Top 10 URL ) for url, cnt in url_counter.most_common(10): print(f{url}: {cnt}) print(\n 请求最多的 10 个时间点 ) for t, cnt in time_counter.most_common(10): print(f{t}: {cnt})把日志路径换成你自己的文件执行python3 analyze_amazonbot.py这个脚本会输出来源 IP 排名、被抓 URL 排名和请求时间分布。有了这些数据你就能知道应该在哪条路径、哪个时间窗口做限流。6. 常见问题与排查思路在实际处理过程中你可能会遇到下面这些问题。这里整理成表格方便按图索骥。问题现象常见原因解决思路robots.txt 已配置Amazonbot 依然抓取规则未匹配或 CDN 缓存旧内容检查 robots.txt 返回内容刷新 CDN 缓存使用 UA 匹配规则在服务器层拦截Nginx 配置了拦截但日志仍有 Amazonbot请求经过 CDNUA 被 CDN 透传但 IP 是 CDN 节点在 CDN 层配置拦截规则或者在 Nginx 里检查 X-Forwarded-For 与原始 UA拦截后真实用户也无法访问UA 规则写得太宽比如匹配了bot关键字缩小匹配范围改为精确匹配Amazonbot并在拦截前测试爬虫使用随机会话 ID 访问页面应用生成了大量带参数的 URL在 URL 规范中禁止搜索引擎收录带参数页面并限制带参数请求频率拦截后服务器负载依然高爬虫已经把请求打到了后端响应慢导致线程堆积先通过日志分析确认命中拦截的比例再优化后端查询、增加缓存、扩容返回 403 后爬虫仍然反复重试部分爬虫对 403 会重试甚至加强频率改用 444 或 429并在 WAF 层做 IP 封禁这里要强调一个排查顺序先看日志再改配置改完配置再看日志确认效果。不要一条规则都没验证就堆上多个拦截手段否则出了问题反而不知道是哪一层造成的。7. 最佳实践与工程建议7.1 拦截方式优先级根据站点规模和流量情况推荐的拦截优先级如下小站点、个人博客Nginx 或 Apache 层按 UA 拦截加上 robots.txt 声明。使用了 CDN 的站点优先 CDN / WAF 层拦截再从源站补一道 Nginx 规则。有后端开发的业务系统在应用层增加限流防止漏网爬虫拖垮数据库。资深运维团队可以基于 Nginx Lua 或 WAF 规则做 IP 信誉库识别动态封禁异常 IP。注意不要一上来就封禁整段亚马逊 IP 段因为亚马逊云服务AWS的 IP 池非常庞大很多正常用户或第三方服务可能也来自同一段 IP直接封段容易误伤。7.2 避免误伤正常用户拦截爬虫最大的风险是误伤。以下几条建议能帮你控制风险先观察日志 1 到 2 天确认 Amazonbot 的请求特征后再配置拦截。使用 UA 包含匹配不要使用“不以 Mozilla 开头”这类过于宽泛的规则。对返回 403 的请求打上独立日志标记方便后续检查是否有真实用户被误拦。如果站点有移动端 App 调用接口要格外小心不能只按 UA 判断还需校验 API Token。7.3 与 Amazon 官方沟通如果你的网站明确不希望被 Amazonbot 抓取除了技术拦截也可以向亚马逊提交反馈。亚马逊提供了面向开发者的 Amazonbot 支持页面你可以通过官方渠道描述你的域名、时间范围、请求日志摘录请求对方将你的站点从抓取列表中移除。沟通时建议附上以下材料你的域名和 robots.txt 线上地址。抓取日志的统计摘要包括时间、频率、UA。已经配置的拦截规则截图或文本。对业务影响的说明例如服务器负载、带宽费用增加。这类申请不一定立刻生效所以技术层面的拦截仍然是必须的。7.4 长期运营建议从长期来看网站应对爬虫不能只靠“一次性拦截”。建议建立一套可持续的流程每季度检查一次访问日志看是否出现新的高频 UA。在日志分析平台ELK、Loki 等配置 UA 维度告警。为所有对外接口设计完善的限流和鉴权机制而不是依赖 robots.txt 保护数据。对接口返回的数据做脱敏处理确保即使被爬走敏感字段也不会泄露。在代码层面统一维护“禁止爬虫名单”将 UA 正则配置放到配置中心或环境变量方便动态调整。如果你把这些建议落地以后再遇到新的爬虫只需要在名单里加一行 UA 规则不用重写一遍架构。8. 总结Amazonbot 的问题本质上是“不受欢迎但合法的爬虫”与“站点资源保护”之间的矛盾。robots.txt 是基础声明但不是安全边界真正有效的是多层拦截与限流组合。这篇文章从 Amazonbot 的概念讲起分析了 robots.txt 失效的常见原因然后给出了 Nginx、Apache、CDN/WAF 和应用层的完整拦截示例。通过日志分析和 Python 统计脚本你可以快速识别爬虫行为验证拦截效果。最后围绕误伤控制、官方沟通和长期监控给出了几条工程级建议。回到 HN 那个帖子的场景如果你也遇到类似情况不妨按这个顺序操作先确认日志特征再改 robots.txt然后加服务器层拦截最后在 CDN 或 WAF 层封禁。每一步做完都回头看一眼日志确认请求是否真的降下来了。只有把识别、拦截、监控连成闭环站点才能在高频爬虫面前保持稳定也才能把资源留给真正有价值的用户。 如何有效拦截Amazonbot：robots.txt失效后的多层防护策略
最近在 Hacker News 上有一个讨论热度很高的标题Amazonbot 疯狂抓取网站甚至无视 robots.txt 规则。很多站长在帖子下面补充了同样的遭遇——明明已经在 robots.txt 里写了Disallow: /访问日志里却依然出现大量来自 Amazonbot 的请求部分请求还能直接命中后端接口把服务器负载拉得很高。这不是个案。Amazonbot 是亚马逊官方推出的网络爬虫和 Googlebot、Bingbot 一样它也有自己的一套抓取规则。但在实际部署中很多站点发现 robots.txt 对它的约束力并不稳定。本文会从 Amazonbot 到底是什么、robots.txt 为什么会被“无视”开始讲起然后逐步给出可落地的识别方案、拦截方案、日志分析方法和工程建议。无论你是个人站长还是公司后端、运维开发都可以按这篇文章的思路去排查和加固自己的站点。1. 背景与核心概念1.1 Amazonbot 是什么Amazonbot 是亚马逊用于抓取公开网页内容的爬虫程序。它主要服务于亚马逊的商品知识图谱、搜索结果增强、以及部分 AI 相关的数据处理链路。你可以把它理解为“亚马逊版 Googlebot”只不过它的抓取目标和抓取策略跟搜索引擎爬虫并不完全一样。从公开资料来看Amazonbot 的默认 User-Agent 通常包含Amazonbot关键字常见形式类似Mozilla/5.0 (compatible; Amazonbot/0.1; https://developer.amazon.com/support/amazonbot)注意这个 User-Agent 是可以被请求方任意伪造的。也就是说你在日志里看到Amazonbot不一定是真的亚马逊爬虫反过来亚马逊爬虫也可能在部分请求中不走标准的 UA 格式。因此后面我们会强调识别爬虫不能只看 User-Agent 一个字段。1.2 robots.txt 为什么会失效robots.txt 是一个放置于网站根目录的纯文本文件它通过User-agent和Disallow/Allow指令告诉爬虫“哪些路径可以抓哪些路径不可以抓”。它本质上是一个君子协议完全依赖爬虫方自觉遵守。robots.txt 失效通常有几种原因规则配置错误User-agent名称匹配不上或者路径写错导致规则没有覆盖到实际请求。缓存问题爬虫侧缓存了旧的 robots.txtCDN 或浏览器缓存也可能会让更新延迟生效。爬虫不遵守部分爬虫在设计时只实现了“读取 robots.txt”的功能但没有严格限制所有子路径也有的爬虫会忽略Crawl-delay等非强制字段。IP 分散抓取爬虫的出口 IP 数量多、地域分散很难用简单的 IP 黑名单完全封闭。回到 HN 那个帖子的场景用户反馈 Amazonbot“无视”robots.txt很可能是因为 Amazonbot 的抓取策略在某些路径上并不严格参考根域名的 robots.txt也可能是 Amazonbot 使用了不同的 UA 或 IP 段导致站点侧的过滤规则没有命中。1.3 这个问题的普遍影响当一只爬虫无视 robots.txt 且高频抓取时实际影响并不只是“多了一点日志”这么简单服务器资源消耗每次抓取都会产生请求处理、数据库查询、日志写入等开销。爬虫频率一高CPU 和带宽占用会明显上升。用户体验变差如果爬虫请求占满了连接池或应用线程真实用户的访问延迟会跟着上升。业务数据风险如果网站存在未做权限校验的接口爬虫可能抓取到本不该公开的数据例如商品价格、库存、用户头像、评论内容等。统计失真高频爬虫会让 PV/UV 统计、热门文章排行等数据变得不可信。所以处理 Amazonbot 的问题并不是“看它不顺眼”才去拦截而是为了保护站点稳定性、数据安全和统计准确性。下面我们从识别开始逐步搭建一套防护方案。2. 问题现象与影响分析2.1 如何判断自己的网站正在被 Amazonbot 抓取要判断是否被 Amazonbot 抓取最直接的方法是查看 Web 访问日志。以 Nginx 为例默认访问日志路径通常是/var/log/nginx/access.log可以用 grep 快速过滤grep -i Amazonbot /var/log/nginx/access.log | tail -n 50如果日志里出现大量 UA 含Amazonbot的请求就说明爬虫已经来过。进一步看你还可以统计单位时间内的请求量grep -i Amazonbot /var/log/nginx/access.log | awk {print $4} | sort | uniq -c | sort -nr | head -n 20这段命令按日期时间统计 Amazonbot 请求数量能看出它是不是在短时间密集抓取。如果站点前面有 CDN比如 Cloudflare、阿里云 CDN、腾讯云 CDN你需要去 CDN 的日志分析功能里查询。很多 CDN 会隐藏源站真实 IP但访问日志里依然保留请求 UA所以查 UA 依然是最快的方式。2.2 高频抓取给站点带来的实际影响我帮你把这个过程拆开来看。假设一个小型网站部署在 2C4G 的云服务器上后端是 Spring Boot MySQL前面用 Nginx 做反向代理。平时每秒请求量大概在 20 左右服务器负载还算健康。当 Amazonbot 开始高频抓取时可能会出现下面这些现象现象原因负载升高CPU 使用率持续 80% 以上大量请求穿透 Nginx到达应用层MySQL 慢查询增多爬虫会沿着详情页链接递归抓取触发大量 SQL 查询真实用户访问变慢Tomcat 或 PHP-FPM 的线程池被爬虫请求占用日志磁盘占用快速增长高频请求导致 access log 和业务日志膨胀第三方接口费用超支如果页面渲染时调用了地图、短信、AI 等付费 API爬虫也会“帮忙”消耗配额最怕的是爬虫抓取那些不应该被公开的 URL比如带参数的搜索页、导出接口、后台预览链接。即使页面没有直接展示敏感数据高频请求也会对系统产生真实压力。2.3 Amazonbot 与普通搜索爬虫的区别很多站点已经习惯了 Googlebot 和 Bingbot 的抓取节奏因此对 Amazonbot 的“进攻性”感受更明显。它们的区别主要在于抓取目标不同搜索引擎爬虫目标是收录页面建立索引Amazonbot 目标偏向商品信息、开放图谱数据和可被用于构建知识体系的内容。抓取深度不同Amazonbot 对商品详情页、价格页、评论页的抓取深度通常更大甚至会把带参数的筛选页也爬一遍。robots.txt 遵守程度不同Googlebot 和 Bingbot 对 robots.txt 的遵守非常严格而 Amazonbot 在不同时间段的策略存在变化社区里也出现了不少“设置后依然被抓”的反馈。这里并不是说 Amazonbot 一定是恶意爬虫只是在你的站点没有向亚马逊提交抓取需求的情况下它带来的负担和风险远大于收益。因此主动在服务器和 CDN 双层做限制是保护站点资源的合理选择。3. robots.txt 原理与 Amazonbot 协议支持3.1 robots.txt 基础语法回顾先快速回顾一下 robots.txt 的基本写法。文件放在网站根目录比如https://example.com/robots.txt。User-agent: * Disallow: /private/ Disallow: /api/ Allow: /public/含义很简单User-agent: *表示作用于所有爬虫。Disallow表示禁止抓取的路径。Allow表示允许抓取的路径。空行表示一组规则结束。robots.txt 的有效性有几个前提文件必须能从公网直接访问返回200 OK。文件内容必须是纯文本不能是 HTML 页面。规则路径是“前缀匹配”不是“全字匹配”比如/api会匹配/api/user、/api/order。如果部署了 CDN记得让 CDN 放行根目录 robots.txt不要对这类小文件做强制缓存否则爬虫读到旧的规则更新就会延迟。3.2 Amazonbot 使用哪些 User-Agent从现有的访问日志统计来看Amazonbot 常见的 UA 主要有这样的格式Mozilla/5.0 (compatible; Amazonbot/0.1; https://developer.amazon.com/support/amazonbot) Mozilla/5.0 (Linux; Android 5.0; SM-G920P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36 (compatible; Amazonbot/0.1; https://developer.amazon.com/support/amazonbot)也就是说它有时会附带移动端浏览器标识但核心标识仍是Amazonbot/0.1。需要注意的是UA 属于可伪造字段。你在日志里看到Amazonbot可能有三类情况真正的亚马逊爬虫。第三方模仿 Amazonbot UA 的采集程序。搜索了 Amazonbot 关键词的安全扫描器。因此靠 UA 做拦截只是第一道防线属于“便宜但有效”的方案。要对更复杂的伪造做识别需要配合反向 DNS 查询和 IP 库校验。3.3 robots.txt 的局限性与绕过方式robots.txt 的局限性在于它本身不具备强制力。它既不能被服务器强制执行也不能被浏览器或 CDN 强制执行。一个爬虫完全可以忽略它继续抓取只是这样做不符合搜索引擎行业的通行规范。常见的“绕过”或“失效”情况包括robots.txt 中只写了User-agent: *但爬虫实际使用的 UA 不在匹配范围内。网站通过 JS 动态渲染页面爬虫抓到的 HTML 只有空壳于是反复重试不同参数。网站存在大量重复 URL比如排序、筛选、分页链接爬虫会认为这些是新的页面持续抓取。CDN 把 robots.txt 缓存了爬虫抓到的还是旧版本等于你的新规则没生效。理解了这些限制我们就能明白不能单靠 robots.txt 来挡住 Amazonbot必须在服务器、CDN、应用层多处设防。4. 完整拦截方案从入口到应用层4.1 方案总览这里给出一个完整的拦截思路从上到下一共五层robots.txt 声明层明确拒绝 Amazonbot 抓取全站。Web 服务器层Nginx / Apache 按 UA 直接返回 403 或 444。CDN / WAF 层在云厂商控制台配置 Bot 管理规则或者自定义拦截规则。应用层对高频请求做限流和频控。监控层日志分析和告警确认识别是否准确、拦截是否生效。下面逐一展开。4.2 第一层完善 robots.txt 与声明在站点根目录创建或修改robots.txt将以下内容加入文件User-agent: Amazonbot Disallow: / User-agent: * Disallow: /private/ Disallow: /admin/ Disallow: /api/这里做两件事单独给 Amazonbot 设置Disallow: /明确表示不欢迎抓取全站。给所有其他爬虫也划定禁区防止它们顺着路径深入。更新 robots.txt 后可以先用 curl 验证是否能正常读取curl -I https://example.com/robots.txt预期返回HTTP/1.1 200 OK Content-Type: text/plain如果你的 CDN 开启了 robots.txt 缓存记得刷新缓存或设置较短的缓存时间。否则爬虫侧拿到旧规则新配置等于白做。4.3 第二层Nginx 层拦截 AmazonbotNginx 适合在入口层面直接处理爬虫请求。它可以在不经过后端应用的情况下直接返回 403对服务器资源的消耗极小。先看一个基于map的判断方案。在http块中配置http { map $http_user_agent $bad_bot { default 0; ~*Amazonbot 1; ~*ChatGPT-User 1; ~*GPTBot 1; } server { listen 80; server_name example.com; if ($bad_bot) { return 403; } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } }关键点说明map $http_user_agent $bad_bot会根据请求头里的 User-Agent 做正则匹配。~*Amazonbot表示不区分大小写匹配包含Amazonbot的字符串。if ($bad_bot) { return 403; }直接在 Nginx 层返回 403后续不再进入后端。如果你希望更“安静”地处理可以把return 403改成return 444。444 是 Nginx 特有的状态码会直接关闭连接不返回任何响应体很多采集程序会把这解读为目标不可达。if ($bad_bot) { return 444; }需要注意Nginx 的if指令在location里使用时有一些历史问题但用在上面的场景中做简单判断是没问题的。如果你是资深用户更推荐使用ngx_http_geo_module建立 IP 段黑名单或者使用 OpenResty 的 Lua 逻辑做更复杂的判断。4.4 第三层Apache 层拦截配置如果站点跑在 Apache 上可以在.htaccess或 httpd 配置中使用mod_rewrite拦截。RewriteEngine On RewriteCond %{HTTP_USER_AGENT} Amazonbot [NC,OR] RewriteCond %{HTTP_USER_AGENT} GPTBot [NC] RewriteRule ^ - [F,L]这段配置的含义是当请求 UA 中包含Amazonbot或GPTBot时返回 403 状态码。NC表示不区分大小写F表示 ForbiddenL表示停止后续规则。如果希望拦截后返回 404而不是 403也可以写成RewriteRule ^ - [R404,L]具体用 403 还是 404取决于你的偏好。403 更明确容易排查404 能让部分爬虫更快放弃因为它们觉得“路径不存在”。4.5 第四层CDN / WAF 层拦截对于已经接入 CDN 的网站在 CDN 层拦截比在源站拦截更高效因为请求在边缘节点就被挡下了不会回源消耗服务器资源。常见操作路径如下登录 CDN 控制台找到“访问控制”或“Bot 管理”。新建一条规则匹配字段选择User-Agent。匹配方式选择“包含”值填写Amazonbot。执行动作选择“拦截”或者“返回指定页面”。以 Cloudflare 为例可以在 WAF 自定义规则中写(http.user_agent contains Amazonbot)动作设置为Block。如果是阿里云 CDN 或腾讯云 CDN通常也支持配置 Referer 防盗链、UA 黑白名单、IP 黑白名单。你可以用 UA 黑名单拦截 Amazonbot也可以用 IP 黑名单拦截后续确认的爬虫 IP 段。CDN 层还有一个好处你可以针对某个路径单独拦截比如只拦截/?s搜索页、/product/商品页避免误伤正常用户访问首页。4.6 第五层应用层速率限制即使前面几层都做了依然可能出现漏网之鱼。比如爬虫伪装成普通浏览器 UA或者通过代理池轮换 IP。此时应用层限流是关键兜底。以 Java Spring Boot 为例可以基于拦截器做一个简单的 IP 路径频率限制。这里只给出一个思路性质的代码示例// 文件路径src/main/java/com/example/demo/config/RateLimitInterceptor.java Component public class RateLimitInterceptor implements HandlerInterceptor { private final MapString, DequeLong requestRecords new ConcurrentHashMap(); private static final int MAX_REQUESTS 60; private static final long WINDOW_MILLIS 60_000L; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String clientIp getClientIp(request); long now System.currentTimeMillis(); DequeLong records requestRecords.computeIfAbsent(clientIp, k - new ArrayDeque()); synchronized (records) { while (!records.isEmpty() now - records.peekFirst() WINDOW_MILLIS) { records.pollFirst(); } if (records.size() MAX_REQUESTS) { response.setStatus(429); response.getWriter().write(Too Many Requests); return false; } records.addLast(now); } return true; } private String getClientIp(HttpServletRequest request) { String xff request.getHeader(X-Forwarded-For); if (xff ! null !xff.isBlank()) { return xff.split(,)[0].trim(); } return request.getRemoteAddr(); } }使用限流方案时要注意几个工程细节单机内存限流在集群环境下不准确需要引入 Redis 做分布式计数。限流要区分正常用户和爬虫尽量只限制高频特征避免误伤。返回 429 后可以在响应头中加入Retry-After让遵守协议的客户端延迟重试。5. 日志分析与监控识别真实抓取行为5.1 从访问日志中提取 Amazonbot 请求在完成拦截之前先要把“敌人”看清楚。对于 Nginx 用户你可以统计一段时间内的 Amazonbot 请求密度awk {print $1, $4, $6, $7} /var/log/nginx/access.log | grep -i Amazonbot | head -n 20输出示例192.0.2.10 [18/Oct/2025:10:25:01 0000] GET /product/a 192.0.2.11 [18/Oct/2025:10:25:03 0000] GET /product/b 192.0.2.10 [18/Oct/2025:10:25:05 0000] GET /product/a?page2通过这个结果你可以看到它是不是在递归翻页、是不是集中抓取某个目录、来源 IP 分布如何。5.2 反查 DNS 确认爬虫身份由于 UA 可以伪造更严谨的验证方法是反查 IP 的 PTR 记录。亚马逊官方爬虫通常有对应的反向 DNS 域名例如*.amazonbot.amazon之类的后缀但这类域名会随地区和服务调整。在 Linux 服务器上可以使用dig或nslookup反查dig -x 192.0.2.10 short如果反查结果中能看到amazon相关域名再结合 UA 包含Amazonbot基本可以确认是官方爬虫。如果反查结果是无意义的云主机 IP例如某个 VPS 服务商的动态 IP而 UA 又伪装成Amazonbot那大概率不是亚马逊官方行为可能是第三方模拟。5.3 使用 Python 快速统计抓取频率如果日志文件较大用 Shell 命令不够灵活可以写一个简单的 Python 脚本来统计。# 文件路径analyze_amazonbot.py import re from collections import Counter from datetime import datetime log_file /var/log/nginx/access.log bot_pattern re.compile(rAmazonbot, re.IGNORECASE) ip_counter Counter() time_counter Counter() url_counter Counter() with open(log_file, r, errorsignore) as f: for line in f: if bot_pattern.search(line): parts line.split() if len(parts) 7: continue ip parts[0] time_str parts[3].strip([]) url parts[6] ip_counter[ip] 1 time_counter[time_str] 1 url_counter[url] 1 print( Top 10 IP ) for ip, cnt in ip_counter.most_common(10): print(f{ip}: {cnt}) print(\n Top 10 URL ) for url, cnt in url_counter.most_common(10): print(f{url}: {cnt}) print(\n 请求最多的 10 个时间点 ) for t, cnt in time_counter.most_common(10): print(f{t}: {cnt})把日志路径换成你自己的文件执行python3 analyze_amazonbot.py这个脚本会输出来源 IP 排名、被抓 URL 排名和请求时间分布。有了这些数据你就能知道应该在哪条路径、哪个时间窗口做限流。6. 常见问题与排查思路在实际处理过程中你可能会遇到下面这些问题。这里整理成表格方便按图索骥。问题现象常见原因解决思路robots.txt 已配置Amazonbot 依然抓取规则未匹配或 CDN 缓存旧内容检查 robots.txt 返回内容刷新 CDN 缓存使用 UA 匹配规则在服务器层拦截Nginx 配置了拦截但日志仍有 Amazonbot请求经过 CDNUA 被 CDN 透传但 IP 是 CDN 节点在 CDN 层配置拦截规则或者在 Nginx 里检查 X-Forwarded-For 与原始 UA拦截后真实用户也无法访问UA 规则写得太宽比如匹配了bot关键字缩小匹配范围改为精确匹配Amazonbot并在拦截前测试爬虫使用随机会话 ID 访问页面应用生成了大量带参数的 URL在 URL 规范中禁止搜索引擎收录带参数页面并限制带参数请求频率拦截后服务器负载依然高爬虫已经把请求打到了后端响应慢导致线程堆积先通过日志分析确认命中拦截的比例再优化后端查询、增加缓存、扩容返回 403 后爬虫仍然反复重试部分爬虫对 403 会重试甚至加强频率改用 444 或 429并在 WAF 层做 IP 封禁这里要强调一个排查顺序先看日志再改配置改完配置再看日志确认效果。不要一条规则都没验证就堆上多个拦截手段否则出了问题反而不知道是哪一层造成的。7. 最佳实践与工程建议7.1 拦截方式优先级根据站点规模和流量情况推荐的拦截优先级如下小站点、个人博客Nginx 或 Apache 层按 UA 拦截加上 robots.txt 声明。使用了 CDN 的站点优先 CDN / WAF 层拦截再从源站补一道 Nginx 规则。有后端开发的业务系统在应用层增加限流防止漏网爬虫拖垮数据库。资深运维团队可以基于 Nginx Lua 或 WAF 规则做 IP 信誉库识别动态封禁异常 IP。注意不要一上来就封禁整段亚马逊 IP 段因为亚马逊云服务AWS的 IP 池非常庞大很多正常用户或第三方服务可能也来自同一段 IP直接封段容易误伤。7.2 避免误伤正常用户拦截爬虫最大的风险是误伤。以下几条建议能帮你控制风险先观察日志 1 到 2 天确认 Amazonbot 的请求特征后再配置拦截。使用 UA 包含匹配不要使用“不以 Mozilla 开头”这类过于宽泛的规则。对返回 403 的请求打上独立日志标记方便后续检查是否有真实用户被误拦。如果站点有移动端 App 调用接口要格外小心不能只按 UA 判断还需校验 API Token。7.3 与 Amazon 官方沟通如果你的网站明确不希望被 Amazonbot 抓取除了技术拦截也可以向亚马逊提交反馈。亚马逊提供了面向开发者的 Amazonbot 支持页面你可以通过官方渠道描述你的域名、时间范围、请求日志摘录请求对方将你的站点从抓取列表中移除。沟通时建议附上以下材料你的域名和 robots.txt 线上地址。抓取日志的统计摘要包括时间、频率、UA。已经配置的拦截规则截图或文本。对业务影响的说明例如服务器负载、带宽费用增加。这类申请不一定立刻生效所以技术层面的拦截仍然是必须的。7.4 长期运营建议从长期来看网站应对爬虫不能只靠“一次性拦截”。建议建立一套可持续的流程每季度检查一次访问日志看是否出现新的高频 UA。在日志分析平台ELK、Loki 等配置 UA 维度告警。为所有对外接口设计完善的限流和鉴权机制而不是依赖 robots.txt 保护数据。对接口返回的数据做脱敏处理确保即使被爬走敏感字段也不会泄露。在代码层面统一维护“禁止爬虫名单”将 UA 正则配置放到配置中心或环境变量方便动态调整。如果你把这些建议落地以后再遇到新的爬虫只需要在名单里加一行 UA 规则不用重写一遍架构。8. 总结Amazonbot 的问题本质上是“不受欢迎但合法的爬虫”与“站点资源保护”之间的矛盾。robots.txt 是基础声明但不是安全边界真正有效的是多层拦截与限流组合。这篇文章从 Amazonbot 的概念讲起分析了 robots.txt 失效的常见原因然后给出了 Nginx、Apache、CDN/WAF 和应用层的完整拦截示例。通过日志分析和 Python 统计脚本你可以快速识别爬虫行为验证拦截效果。最后围绕误伤控制、官方沟通和长期监控给出了几条工程级建议。回到 HN 那个帖子的场景如果你也遇到类似情况不妨按这个顺序操作先确认日志特征再改 robots.txt然后加服务器层拦截最后在 CDN 或 WAF 层封禁。每一步做完都回头看一眼日志确认请求是否真的降下来了。只有把识别、拦截、监控连成闭环站点才能在高频爬虫面前保持稳定也才能把资源留给真正有价值的用户。