这次的讨论焦点不是某个新模型，也不是一个开源框架，而是一个让站点维护者非常头疼的现实问题： Amazonbot 在被大量网站管理员反馈后，仍然存在无视 robots.txt 抓取站点内容的行为。Hacker News 上有用户发帖“Tell HN: Amazonbot aggressively scraping my website and ignoring robots.txt”，引出了爬虫治理、 robots.txt 执行力、日志分析和服务器拦截这一整套运维需求。

先说结论： robots.txt 本质上是一份“君子协定”，它只对愿意遵守规则的爬虫有效，并不能对违规爬虫形成强制约束。所以当 Amazonbot 这类爬虫不给情面时，仅靠修 robots.txt 远不够，必须叠加服务器层、防火墙层、甚至是 CDN/WAF 层的多重拦截。下面直接给出从流量识别到强制拦截的完整方案，核心内容围绕日志分析、UA 规则、IP 封禁和监控脚本展开，你可以直接复制配置到自己的 Nginx 或 Apache 环境里验证。

1. 核心问题速览

项目	说明
问题类型	爬虫抓取、流量治理、robots.txt 被无视
针对对象	Amazonbot（亚马逊官方爬虫）
核心原因	robots.txt 是非强制协议，部分爬虫会忽略
主要症状	访问日志中大量 Amazonbot UA 请求，日志量暴增，带宽和 CPU 被占用
应对手段	robots.txt 声明、UA 拦截、IP 封禁、CDN/WAF 规则、监控告警
适用环境	Nginx、Apache、Linux 防火墙、Cloudflare 等 CDN/WAF
配置门槛	中低，需要服务器登录权限和基本命令行操作能力
是否依赖 GPU	否，纯运维和 Web 服务器配置问题

这里需要先解释一下：Amazonbot 是亚马逊的爬虫，官方在开发者页面说明它会用于改善搜索结果、知识问答等场景，并且声明遵守 robots.txt 。但从大量站长反馈来看，实际行为与声明不一致，抓取频率高、覆盖范围广，有时候即使返回 403 也会继续尝试。所以更稳妥的判断是：不要指望它主动收敛，要在服务器入口直接拦住。

2. 适用场景与使用边界

这套方案适合以下几类人：

• 个人站长或小团队，服务器带宽和 CPU 资源有限，不希望爬虫消耗过多资源。
• 有内容版权保护需求，不希望站点全文被第三方爬虫抓取用于 AI 训练、知识库构建等用途。
• 已经在日志里看到大量 Amazonbot 请求，想快速判断影响范围并做拦截。
• 想建立一套可复用的“恶意/高消耗爬虫治理流程”，不只针对 Amazonbot，也可以套用到其他不规范爬虫。

它不适合哪些场景呢？如果你的业务本身就是给亚马逊或搜索引擎提供数据，或者你就是靠爬虫生态吃饭，那就需要先评估是否愿意放行 Amazonbot。另外，如果站点已经接入企业级 WAF，通常可以在 WAF 里配置托管规则，不一定需要改源站配置。

使用边界方面，强调几点合规和安全要求：

• 你有权对自己服务器上的访问行为做限制，拒绝某个 UA 或 IP 是正当的站点治理手段。
• 不要对 Amazonbot 的 IP 执行全网段误封，AWS 的 IP 范围很大，里面可能混有其他正常服务流量，封禁前必须通过日志确认。
• 保留拦截前日志作为备份，方便后续申诉或排查误杀。
• 如果站点包含用户生成内容，需要同步考虑隐私和版权保护，避免第三方抓取后非授权使用。

3. 前置条件与准备工作

开始之前，确保你具备下面这些条件。

3.1 服务器权限

配置拦截规则需要能进入服务器，建议准备一个具备 sudo 权限的用户。如果你用的是云服务器，最好在控制台安全组里先放行自己的 IP，避免改防火墙时误伤。

3.2 Web 服务器类型确认

先确认自己用的是 Nginx、Apache 还是其他 Web Server。

# Debian/Ubuntu
nginx -V

# CentOS/RHEL
nginx -v

# Apache
apache2 -v
httpd -v

后面的配置示例会分别给出 Nginx 和 Apache 的写法。

3.3 日志位置确认

不同环境日志位置不同，下面是常见路径。

服务	日志路径
Nginx（Debian/Ubuntu）	/var/log/nginx/access.log
Nginx（CentOS/RHEL）	/var/log/nginx/access.log
Apache（Debian/Ubuntu）	/var/log/apache2/access.log
Apache（CentOS/RHEL）	/var/log/httpd/access_log
Docker 容器内的 Nginx	通过 docker logs 或挂载的日志目录查看

3.4 检查 robots.txt 现有配置

先看一下当前站点根目录下的 robots.txt 内容。需要确认被爬的是哪个域名，以及 robots.txt 是否能正常访问。

curl -s http://your-domain.com/robots.txt | head -50

4. 确认流量：从访问日志里识别 Amazonbot

网站访问量突然升高，先别急着猜，直接看日志。

4.1 查询 Amazonbot 请求数量

# 统计今天日志中 Amazonbot 请求总数
grep "Amazonbot" /var/log/nginx/access.log | wc -l

# 统计过去几天的日志
grep "Amazonbot" /var/log/nginx/access.log* | wc -l

如果你看到请求数量上千甚至上万，说明抓取已经很频繁了。

4.2 查看 Amazonbot 的 UA 样例

拿到若干条具体的请求行，确认 UA 特征。

grep "Amazonbot" /var/log/nginx/access.log | head -5

常见输出会包含这样的 UA 片段：

Mozilla/5.0 (compatible; Amazonbot/0.1; +https://developer.amazon.com/support/amazonbot)

但需要注意，UA 很容易被伪造，不要只看这一个字段，要结合来源 IP 和访问路径一起判断。

4.3 统计高频来源 IP

grep "Amazonbot" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

输出示例：

875 203.0.113.10
432 198.51.100.23
117 192.0.2.45

如果某个 IP 的请求量明显高于其他，优先对这个 IP 做持续观察，必要的时候封禁。

4.4 确认抓取路径特征

再确认一下爬虫重点抓的是哪些页面，这关系到后面是否需要针对动态 URL 做更细的拦截。

grep "Amazonbot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

如果抓取路径集中在 / 、 /products/ 、 /articles/ 等核心页面，说明全站内容都在被采集，需要尽快拦截。

5. 配置 robots.txt：先声明规则

这一步不是必须，但建议先做，理由是留有证据：你确实已经声明过规则，后续即使需要举证，也有据可查。修改后的 robots.txt 如下。

User-agent: *
Disallow: /admin/

User-agent: Amazonbot
Disallow: /
Crawl-delay: 10

这段配置的意思是：Amazonbot 不允许抓取全站内容，并且抓取间隔至少 10 秒。 Crawl-delay 不是所有爬虫都支持，只是一个协商参数，但对部分尊重协议的爬虫有一定约束力。

改完后刷新验证：

curl -s http://your-domain.com/robots.txt | grep -A3 "Amazonbot"

不过必须明确： robots.txt 没有强制执行能力，它不依赖任何技术机制，也不像 HTTP 状态码那样有强约束。爬虫完全可以选择忽略。因此下面这部分才是真正有效的措施。

6. 强制拦截：UA、IP、防火墙三层配置

只有把拦截放到 Web 服务器或防火墙层，才能真正挡住 Amazonbot 的抓取请求。

6.1 Nginx 拦截 Amazonbot UA

推荐用 map 模块统一管理爬虫 UA 黑名单，这样可维护性最好。

在 nginx.conf 的 http 块中加入：

http {
    # 这里定义需要拦截的爬虫 UA
    map $http_user_agent $blocked_bot {
        default 0;
        "~*Amazonbot" 1;
        "~*Amazonbot/0.1" 1;
    }

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

然后在目标 server 块顶部加入判断：

server {
    listen 80;
    server_name your-domain.com;

    # 如果是 Amazonbot UA，直接返回 403
    if ($blocked_bot) {
        return 403;
    }

    # 其他正常配置
    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

修改之后先测试配置：

nginx -t

然后重载：

systemctl reload nginx

验证方式：

curl -A "Mozilla/5.0 (compatible; Amazonbot/0.1; +https://developer.amazon.com/support/amazonbot)" -I http://your-domain.com/

预期返回 403。

6.2 Apache 拦截 Amazonbot UA

Apache 可以使用 mod_rewrite 拦截，也可以直接在 .htaccess 或虚拟主机配置里写。顶层配置示例：

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "Amazonbot" [NC]
RewriteRule .* - [F,L]

[F] 表示返回 403， [L] 表示停止匹配。放在虚拟主机配置里即可。

<VirtualHost *:80>
    ServerName your-domain.com

    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} "Amazonbot" [NC]
    RewriteRule .* - [F,L]

    DocumentRoot /var/www/html
</VirtualHost>

修改后测试配置并重启：

apache2ctl configtest
systemctl reload apache2

6.3 封禁高频来源 IP

如果某些 IP 持续高并发抓取，即使不是 Amazonbot UA，也会消耗大量资源，可以单独封禁。先把高频 IP 提取出来：

grep "Amazonbot" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | awk '$1 > 500 {print $2}' > /tmp/amazonbot_hot_ips.txt

这个命令会筛选出请求次数超过 500 的 IP，接下来手动检查一下这些 IP 是否都是爬虫。确认后，逐条加入防火墙：

while read ip; do
    iptables -A INPUT -s "$ip" -j DROP
done < /tmp/amazonbot_hot_ips.txt

也可以只限制 80/443 端口：

while read ip; do
    iptables -A INPUT -p tcp --dport 443 -s "$ip" -j DROP
    iptables -A INPUT -p tcp --dport 80 -s "$ip" -j DROP
done < /tmp/amazonbot_hot_ips.txt

注意：iptables 规则重启后可能丢失，生产环境建议配合 iptables-persistent 或写成启动脚本。

如果服务器使用的是 firewalld，可以使用：

while read ip; do
    firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=$ip port port=443 protocol=tcp drop"
done < /tmp/amazonbot_hot_ips.txt

firewall-cmd --reload

6.4 通过 CDN / WAF 层拦截

如果站点套了 Cloudflare 或其他 CDN/WAF，建议在 CDN 层先拦截，这样请求根本到不了源站。Cloudflare 的做法是添加 WAF 自定义规则。

规则可以按以下条件配置：

• User Agent 包含 Amazonbot
• 威胁分数超过某个阈值
• 请求频率超过设定值

例如 Cloudflare 自定义 WAF 规则表达式：

(http.user_agent contains "Amazonbot")

动作设置为 Block。这样可以在边缘节点直接拦截，降低源站压力。

如果你用其他 WAF，逻辑类似：在请求头或 UA 匹配阶段拦截，并返回 403 或 429。

7. 日志监控与持续追踪

拦截并不是一劳永逸的。爬虫可能换 UA、换 IP，所以要把监控做成可持续的流程。

7.1 定时统计脚本

可以写一个简单的 Shell 脚本，每天统计一次 Amazonbot 请求量和高频 IP。

#!/bin/bash

LOG_FILE="/var/log/nginx/access.log"
DATE=$(date +%Y-%m-%d)

echo "===== Amazonbot request summary: $DATE ====="
grep "Amazonbot" "$LOG_FILE" | wc -l

echo ""
echo "===== Top 10 Amazonbot IPs ====="
grep "Amazonbot" "$LOG_FILE" | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

保存为 /usr/local/bin/check_amazonbot.sh ，添加执行权限并用 crontab 定时运行。

chmod +x /usr/local/bin/check_amazonbot.sh

# 每天 8 点执行
crontab -e
0 8 * * * /usr/local/bin/check_amazonbot.sh >> /var/log/amazonbot_monitor.log 2>&1

7.2 设置异常告警

当请求量超过阈值时，可以通过邮件或 Webhook 通知。下面是简单的邮件告警片段：

#!/bin/bash

LOG_FILE="/var/log/nginx/access.log"
COUNT=$(grep -c "Amazonbot" "$LOG_FILE")
THRESHOLD=1000

if [ "$COUNT" -gt "$THRESHOLD" ]; then
    echo "Amazonbot requests exceeded threshold: $COUNT" | mail -s "Amazonbot scraping alert" your-email@example.com
fi

如果不想配邮件，也可以写成发送到企业微信、钉钉或 Slack 的 Webhook。

7.3 观察拦截是否生效

拦截之后，持续观察一段时间。如果日志里 Amazonbot 请求开始返回 403，说明 UA 拦截生效；如果请求数反而上升，说明爬虫可能在换 UA 或换 IP，需要进一步分析。这时候再看来源 IP 特征和请求头里的其他字段。

8. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
robots.txt 已配置 Disallow，但仍有 Amazonbot 请求	robots.txt 是非强制协议，爬虫不遵守	看日志确认 UA 和请求量	叠加服务器层 UA 拦截
UA 拦截后仍收到大量请求	爬虫可能带其他 UA 或伪造 UA	按 IP 和请求路径统计	封禁高频 IP，启用 WAF 规则
封禁 IP 后抓取量继续增加	AWS 的 IP 段较大，爬虫不断更换来源	分析日志，看是否有多个高频率 IP	维护动态封禁脚本，联动 CDN
Nginx 返回 403 后仍有请求	返回 403 不代表爬虫会停止发送请求	观察完整 access 日志	追求更低资源消耗时，可在防火墙/DROP 层拦截
404 页面也在被抓取	爬虫在探测非真实 URL	对比抓取路径和站点真实 URL	在 WAF 增加异常路径规则，临时封禁
拦截后正常用户被误伤	存在用户使用共享 IP 或代理访问	对比正常用户 UA 和访问特征	缩小封禁范围，优先按 UA+IP 组合判断
重启后 iptables 规则丢失	iptables 默认不持久化	重启前测试规则	用 iptables-persistent 或 firewalld 保存
日志里找不到 Amazonbot UA	爬虫使用了其他 UA 或域名下线	检查 access.log 的 UA 分布	用访问频率和 IP 特征识别异常爬虫

9. 最佳实践与合规提醒

到这一步，你已经具备了基础的拦截能力。但经验上仍建议按下面的顺序来组织整个防御逻辑。

9.1 分层防御

把拦截分为四层，优先在成本最低的层面处理：

1. robots.txt：声明规则，留凭证。
2. CDN/WAF：边缘拦截，挡掉大部分流量，源站压力最小。
3. Web Server：Nginx/Apache 的 UA 拦截，作为第二道防线。
4. 防火墙：针对高频 IP 的最终手段。

9.2 所有拦截都要可回滚

每加一条规则之前，先在测试环境或非关键路径上验证，并且保留一周以内的访问日志。万一出现误伤，可以依据日志回溯并快速解封。

9.3 保留证据

如果后续需要向云服务商、CDN 服务商或对方申诉，日志就是最直接的证据。建议导出拦截前一段时间的原始日志，包括请求时间、来源 IP、UA、请求路径和响应状态码。

9.4 合规提醒

• 对爬虫做拦截属于站点管理者的正当权限范围，但不要让拦截扩大到无关 IP，尤其不要因为某个云厂商的 IP 段里有违规爬虫就把整个云厂商全部封死，容易误伤正常用户。
• 如果站点内存在第三方内容或用户生成内容，在拦截并处理爬虫时，也需要遵守隐私合规要求，不要擅自公开用户 IP 或敏感日志。
• 如果确实有版权或数据安全问题，建议优先技术控制和申诉流程，保持沟通记录。

10. 总结

这次讨论的核心在于：robots.txt 是声明，不是执法工具。处理 Amazonbot 这类不遵守协议的爬虫，最有效的路径是把它当作流量治理问题来解决，按“确认日志 -> 声明规则 -> 服务器层拦截 -> 防火墙/IP 封禁 -> 持续监控”的顺序逐步收紧。

最值得先做的一步是日志确认：先统计访问日志里的 Amazonbot 请求量和高频 IP，判断影响范围。最容易踩的坑是只改 robots.txt 不做服务器拦截，或者封禁时误伤共享 IP 正常用户。后续如果抓取仍然不止，可以继续扩展成自动化的爬虫识别与封禁脚本，把这类问题纳入日常运维监控体系。建议收藏备用，等日志里再出现这种高消耗爬虫时，直接按这套流程处理。