凌晨三点，Nginx 的 access.log 里突然多了一批“看起来很正常”的请求：User-Agent 写着 ClaudeBot、GPTBot，IP 分散在几个海外 IDC 网段，浏览器的 Accept 字段也完全符合爬虫特征。如果你只扫一眼 UA，大概率会把它当成 AI 厂商派来的爬虫，顺手放行然后继续睡觉。
但把请求路径拉出来看，就是完全不同的故事了：/.env、/wp-login.php、/.git/HEAD、/config.php.bak、/admin/config.php，这些路径没有任何一个内容是 AI 模型抓取网页所需要的。这不是 AI 来访问你的网站，而是有人在利用 AI 爬虫的名义做大规模漏洞扫描。
更麻烦的是，这种流量对防御者来说非常“膈应”：直接封掉 ClaudeBot 的 UA，可能把 Anthropic 真实的内容抓取也一并挡掉；不封，攻击者就可以继续用合法合规的 UA 探测你的应用漏洞，一步一步试探出.env、.git、备份文件等敏感资产。
这篇文章不讨论恐吓式的安全情报，只讲三件事：第一，为什么 AI 爬虫 UA 现在是攻击者最喜欢的“隐身衣”；第二，如何在 Nginx 的访问日志里通过行为画像识别真正的漏洞扫描，而不是误伤正常爬虫；第三，用 Nginx、fail2ban、CDN/WAF 三层手段做防护，既能拦截扫描，又不影响真实 AI 爬虫和搜索引擎收录。
1. 什么是伪装 AI 爬虫的漏洞扫描
1.1 现象：UA 合规，行为违规
传统意义上的漏洞扫描器，UA 特征非常明显。sqlmap、nuclei、Nikto、AWVS的请求头一看就知道是自动化工具，WAF 和反爬系统可以轻松识别并拦截。攻击者也明白这一点，所以他们开始往 UA 里塞“正规军”的名字。
伪装 AI 爬虫的漏洞扫描，指的就是攻击者在发送探测请求时，把 HTTP 头里的User-Agent设置为ClaudeBot、GPTBot、PerplexityBot、Google-Extended等 AI 公司官方爬虫的标识，然后对目标站点发起漏洞探测和敏感文件扫描。
从协议层面看，这完全不违反任何规则。HTTP 协议的User-Agent字段本来就是客户端自报家门，服务器无法校验它的真实性。攻击者只是利用了“服务器信任 UA”这一习惯，把自己的扫描流量伪装成合法 AI 爬虫，让防御者在日志审计、WAF 规则、反爬策略上都更难下手。
1.2 为什么是 AI 爬虫，而不是搜索引擎爬虫
过去几年，站长对搜索引擎爬虫已经有了一套成熟的识别和管控方法：Googlebot 官方会公布网段，百度、必应也有对应的反向解析验证方式，很多安全设备都能基于 IP 验证 UA 的真实性。作为对比，AI 爬虫的管理体系还没完全建立起来，它有几个攻击者非常喜欢的特征：
- 信任度高。AI 厂商爬虫往往被默认视为“合法内容采集者”，管理员即使反感，也不会像对待漏洞扫描器那样直接封禁。
- 识别困难。AI 爬虫的数量还在快速变化，官方 UA 列表和 IP 网段缺乏统一、长期稳定的公开数据库，很多站长根本分不清某个 UA 是不是真的。
- 管理宽松。许多站点的 robots.txt 对 AI 爬虫是放行状态，甚至没有单独限制，给了攻击者可乘之机。
于是，攻击者只需要在扫描工具里加上一行-A "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://claudebot.example.com)"，一整轮扫描流量的“身份”就从“可疑攻击者”变成了“AI 内容采集”。
1.3 与普通漏洞扫描的差异
普通漏洞扫描和伪装 AI 爬虫的扫描，在技术能力上没有本质差异，但在防御难度上差了一个量级。
普通扫描器发出请求时，其 UA 特征、请求频率、请求路径组合都高度模板化，安全设备很容易从流量中提取指纹。伪装 AI 爬虫的扫描则把 UA 伪装这一层补齐了，导致传统的“按 UA 封禁”策略完全失效。如果站点开启了 WAF 并且只按 UA 规则处置，攻击者只要换一个合理的爬虫名就能绕过第一道防线。
更需要注意的是，这类扫描往往是有组织、有步骤的：第一天探域名和端口，第二天扫.git、.env等敏感文件，第三天根据响应码批量尝试已知框架漏洞。如果你在日志里看到类似 ClaudeBot 的 UA 频繁访问上述路径，说明攻击者已经进入了“资产测绘 + 漏洞验证”阶段，后续可能跟上来的是实际利用、上传 webshell、植入挖矿脚本或者勒索加密。
2. User-Agent 为什么不可信
2.1 UA 是 HTTP 协议里的“自报家门”
很多新手运维第一次看到被伪装成 ClaudeBot 的扫描请求时会很困惑：难道 Anthropic 官方还会帮攻击者提供伪造的爬虫 UA 吗？
实际上，User-Agent 本身只是 HTTP 请求头里的一个普通字段，客户端可以填写任意字符串。协议设计者从未假设这个字段真实可信，它更像是一个礼貌性的自我介绍，而不是身份凭证。浏览器可以伪造它，爬虫可以伪造它，curl 也可以伪造它。
curl -A "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://claudebot.example.com)" \ -I https://your-site.com/.env上面这条命令，就能在目标服务器日志里留下一条“ClaudeBot 访问 .env 文件”的记录。如果管理员只看 UA 就判断这是 AI 爬虫，不去检查 IP 来源和请求路径，就会忽略一次真实的漏洞探测。
2.2 基于 UA 的安全策略为什么不可靠
既然 UA 可以被任意伪造，那么任何“只依赖 UA 区分正常爬虫和攻击流量”的策略，本质上都建立在沙滩上。
安全设备如果直接封禁所有带ClaudeBot的 UA，这在一段时间内可以挡住无脑复制型攻击者，但代价是误伤真实 AI 爬虫。反过来，如果完全放行这类 UA，又会给攻击者留下一条无障碍通道。更合理的判断是：UA 只能作为线索之一，不能作为信任根。
2.3 Cloudflare Bot 管理模式的启示
一些 CDN/WAF 产品提供 Bot 管理能力，例如在 Cloudflare 后台的 Security → Bots 页面，可以通过 Bot Fight Mode 或 Bot Management 模式来识别和处置自动化请求。它的核心判断依据并不仅仅是 UA，还包括 IP 信誉、浏览器指纹、TLS 指纹、请求行为等多个维度。
从运维实践来看，如果直接把 Bot Management 模式调到最严格，确实能拦住大量伪装扫描，但也会带来副作用：真实 AI 爬虫同样可能被判定为 Bot 并拦截，导致依赖 AI 爬虫做站内内容索引或数据分析的业务数据明显减少。更稳妥的做法，是把 Bot 管理设置为“挑战”或“监控”级别，同时配合自定义 WAF 规则，只在满足“特定 UA + 敏感路径”这种组合时才进行阻止。
3. 真实 AI 爬虫和伪装扫描的行为画像对比
要识别伪装成 ClaudeBot、GPTBot 的漏洞扫描，不能只看单一字段，而是要看一整组行为特征。下面这张表，是运维人员最常用的判断框架：
| 维度 | 真实 AI 爬虫 | 伪装漏洞扫描 |
|---|---|---|
| User-Agent | 官方 UA，字符串通常稳定，与官方文档一致 | 伪造官方 UA，可能有大小写、参数、版本号差异 |
| 请求路径 | robots.txt、文章页、首页、导航链接等公开内容 | /.env、/.git/HEAD、/config.php.bak、/wp-login.php、/admin |
| 请求频率 | 有节流，单位时间请求量合理 | 高频、突发、并发明显偏高，可能几分钟内扫完全站 |
| 来源 IP | 官方公告网段或大型云厂商 IP | 分散的 VPS、IDC、代理池，常有低信誉网段 |
| 响应码关注 | 主要看内容是否可抓取，对 404 基本不重复探测 | 会反复探测 403/404/500 等响应，寻找可利用端点 |
| Referer / 其他头 | 通常会有对应的爬虫说明链接 | 可能为空，或看起来像自动化库生成的请求头 |
这张表的重点不是让你逐项核对，而是让你形成“行为画像”的思维。真实 AI 爬虫的目的是采集公开内容，它没有理由访问.env、.git、备份文件这类敏感路径。如果一个 UA 看起来是 ClaudeBot，同时访问了/.env，那结论基本只有一个：这个 UA 是伪造的，或者这个 IP 已经被攻击者控制。
在实际日志里，这类请求往往还遵循一个时间规律：攻击者习惯在凌晨或业务低峰期发起扫描，因为此时告警响应最慢，日志也会被淹没在海量正常请求中。如果你发现某一批“AI 爬虫”请求集中出现在凌晨 2 点到 5 点，并且路径集中在敏感文件上，就需要尽快处理了。
4. 环境准备与攻击场景重现（以 Nginx 为例）
4.1 环境说明
这套防护思路不依赖特定版本。下面演示以 Linux 服务器 + Nginx 为主要环境，版本请以实际项目为准，重点在于通用排查思路和配置模板。
开始之前，你需要确认三件事：
- 服务器上安装了 Nginx，并且访问日志已开启。
- 知道 access.log 的文件路径，常见位置是
/var/log/nginx/access.log。 - 有通过 shell 查看日志的权限（sudo 权限更佳）。
如果你使用 Apache、腾讯云 CLB、阿里云 SLB 或其他 Web 服务，命令和配置路径需要做相应调整，但核心思路是一样的。
4.2 配置合理的 Nginx 访问日志格式
默认的 Nginx 日志格式是combined，通常包含客户端 IP、时间、请求方法、请求路径、状态码、User-Agent。如果你的日志里看不到 X-Forwarded-For，并且站点使用了 CDN 或负载均衡，建议自定义一个能记录真实 IP 的日志格式。
# 文件路径：/etc/nginx/nginx.conf http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; }修改后重新加载 Nginx：
# 检查配置文件语法 nginx -t # 重新加载配置 nginx -s reload这一步不是必须的，但如果日志格式里缺失 User-Agent 或请求字段，后面的分析命令就无法工作。
4.3 一个典型的伪装扫描请求长什么样
假设攻击者使用某扫描工具，把 UA 设置为ClaudeBot，对example.com发起敏感文件探测。在 Nginx 日志里，你会看到类似下面这样的记录：
203.0.113.10 - - [03/Oct/2025:03:17:42 +0000] "GET /.env HTTP/1.1" 404 162 "-" "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://claudebot.example.com)" 203.0.113.10 - - [03/Oct/2025:03:17:43 +0000] "GET /.git/HEAD HTTP/1.1" 404 162 "-" "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://claudebot.example.com)" 203.0.113.10 - - [03/Oct/2025:03:17:44 +0000] "GET /wp-login.php HTTP/1.1" 404 162 "-" "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://claudebot.example.com)"注意这里的 IP203.0.113.10是文档保留地址，用于示例。正式的 ClaudeBot 官方爬虫是否请求过这些路径，需要结合它的 IP 网段和官方规则判断。但从行为上看，一个内容爬虫连续访问.env、.git、wp-login.php，几乎不可能是正常抓取。
5. 日志分析：从海量请求中锁定可疑源
5.1 统计 UA 带 ClaudeBot 的请求 Top 10 IP
日志分析最常见的起点，是先看看哪些 IP 在使用 AI 爬虫 UA，并且请求量异常突出。
# 在 access.log 中统计 UA 带 ClaudeBot 的请求，按 IP 取 Top 10 grep -i "ClaudeBot" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10如果某个 IP 的请求量在一个时间段内突然飙升到几千次，而且路径几乎全是敏感文件，那这基本就是扫描器在运行。
5.2 查看某个 IP 请求过的完整路径
找出 Top IP 之后，下一步是看这个 IP 到底请求了哪些路径。
# 查看指定 IP 在日志中的所有请求路径 grep -i "ClaudeBot" /var/log/nginx/access.log | grep "203.0.113.10" | awk '{print $7}' | sort | uniq -c | sort -rn | head -30这一步的核心是判断路径的“攻击特征浓度”。正常 AI 爬虫访问的路径一般是/、/about、/blog/xxx这类可读 URL；漏洞扫描器访问的路径则高度集中在敏感文件和框架管理端点上。
如果 Top 路径是/.env、/.git/HEAD、/config.php.bak、/actuator/health、/wp-login.php，并且这些请求都来自低信誉 IP 段，那就应该立刻进入防护流程。
5.3 观察请求的时间规律
# 按小时统计带 ClaudeBot UA 的请求量 grep -i "ClaudeBot" /var/log/nginx/access.log | awk '{print $4}' | sed 's/\[//' | cut -d: -f1-2 | sort | uniq -c正常 AI 爬虫的抓取分布通常比较均匀，或者集中在目标站点的“被允许抓取”时段。如果大量请求集中在凌晨两三点，并且带有明显的路径探测特征，说明攻击者正是利用低峰期在测试你的防护水平。
5.4 形成一套可复用的分析模板
建议把上面几条命令保存为一个 shell 脚本，放到服务器上，需要时直接执行。脚本输出三份内容：可疑 UA 请求的 IP 排行、可疑路径排行、时间分布。有了这些信息，再决定是否封禁，而不是看到一条日志就立刻动手。
6. Nginx 层防护：从黑名单到限流两种策略
6.1 敏感路径兜底拒绝：不区分 UA，无条件 403
识别和分析是第一步，真正要落地的是防护。最基础、最不容易误伤的规则，是对所有敏感路径做无条件拒绝。
# 文件路径：/etc/nginx/sites-available/example.com.conf server { listen 80; server_name example.com; # 第一步：敏感路径兜底，任何来源都不允许 location ~ ^/(\.env|\.git|config\.php\.bak|\.bak|\.sql|wp-login\.php|admin/?) { deny all; return 403; } # 正常业务 location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这条规则的好处是：它不关心 UA 是不是 ClaudeBot，也不关心攻击者换了什么扫描器，只要请求路径命中敏感文件列表，就直接返回 403。即使未来出现新的扫描工具、新的伪造 UA，只要它扫描的目标还是.env、.git、备份文件，就会被挡住。
在 Nginx 中，location ~是正则匹配，优先级高于普通前缀匹配。deny all配合return 403可以被大多数扫描器识别为“该路径不可访问”，从而减少后续探测。
6.2 基于 UA + IP 的精确拦截：放行白名单，拦截未知来源
只做路径兜底，还不能应对所有场景。比如攻击者直接把目标路径换成/wp-json/或/api/user/list，此时仍然是扫描行为，但路径不敏感，上面的规则不会命中。
针对这种情况，可以引入“AI 爬虫 UA 识别 + IP 白名单”组合策略。思路是：只有当请求同时满足“UA 属于 AI 爬虫”和“来源 IP 不在官方白名单”这两个条件时，才判定为可疑并返回 403。
# 文件路径：/etc/nginx/nginx.conf http { # 识别疑似 AI 爬虫 UA map $http_user_agent $ai_bot { default 0; "~*ClaudeBot" 1; "~*GPTBot" 1; "~*PerplexityBot" 1; "~*Google-Extended" 1; } # 管理员已核实的 AI 爬虫真实 IP 网段 geo $real_ai_ip { default 0; # 请替换为 AI 厂商官方公告的真实网段 203.0.113.0/24 1; } server { listen 80; server_name example.com; # 敏感路径兜底 location ~ ^/(\.env|\.git|config\.php\.bak|\.bak|\.sql|wp-login\.php) { return 403; } location / { set $block_flag 0; if ($ai_bot = 1) { set $block_flag 1; } if ($real_ai_ip = 1) { set $block_flag 0; } if ($block_flag = 1) { return 403; } # 正常业务代理 proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } }这段配置的核心逻辑是：如果 UA 看起来是 AI 爬虫，但来源 IP 不在已核实的官方网段内，就直接拒绝。这比单纯封 UA 更精准，误伤真实爬虫的概率大幅降低。
需要强调的是，203.0.113.0/24只是示例网段。实际使用前，应该去各 AI 厂商官方公开页面核对网段和 UA 字符串，不要照搬任何来源不明的列表。
6.3 对疑似 Bot 请求限流：即使放行，也不能让它扫得舒服
有些场景下，你不想对某种 UA 直接返回 403，因为可能影响特定业务。这时可以退而求其次：限流。让疑似 AI 爬虫的请求频率降到一个“扫描器无法忍受”的水平。
# 文件路径：/etc/nginx/nginx.conf http { # 限制单个 IP 每分钟最多 20 个请求 limit_req_zone $binary_remote_addr zone=ai_scan_limit:10m rate=20r/m; server { location / { limit_req zone=ai_scan_limit burst=10 nodelay; proxy_pass http://127.0.0.1:8080; } } }这里给所有客户端加了一个比较宽松的限流：每分钟 20 个请求，突发 10 个。如果某个 IP 在短时间内发起大量连续扫描请求，就会触发503 Service Unavailable或429 Too Many Requests，让扫描效率大幅下降。
实际生产环境中，不建议把限流阈值设得太低，否则会影响到正常用户的浏览。建议先观察业务高峰期请求量，再设置一个相对保守的阈值，例如普通用户每秒不超过 5 个请求。
6.4 变更流程：测试、备份、回滚
修改 Nginx 配置属于偏高风险操作，上线前必须做三件事：
- 备份当前配置文件：
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak。 - 执行
nginx -t验证语法。 - 在测试环境或低峰期灰度发布，观察业务请求是否出现明显异常。
如果配置导致异常，只需要恢复备份并重新加载即可：
cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf nginx -t nginx -s reload7. fail2ban 自动封禁与 CDN/WAF 联动
7.1 fail2ban 配置：按“UA + 路径 + 频率”自动封禁
Nginx 层的拦截是“被动挡”，fail2ban 则是“主动封”。fail2ban 会实时读取 access.log，当匹配到可疑规则的请求次数超过阈值时，自动调用防火墙规则封禁来源 IP 一段时间。
先创建一个 filter 文件，定义什么日志格式属于可疑扫描：
# 文件路径：/etc/fail2ban/filter.d/ai-bot-scan.conf [Definition] failregex = ^<HOST> .* "(GET|POST) \S+? (?:\.env|\.git|config\.php\.bak|\.bak|\.sql|wp-login\.php).*" 403 .*"(?:ClaudeBot|GPTBot|PerplexityBot)" ignoreregex =然后在 jail.local 中启用这个 filter：
# 文件路径：/etc/fail2ban/jail.local [ai-bot-scan] enabled = true port = http,https filter = ai-bot-scan logpath = /var/log/nginx/access.log maxretry = 5 findtime = 60 bantime = 3600 action = iptables-multiport[name=ai-bot-scan, port="http,https"]解释一下这里的参数：
maxretry = 5：在findtime60 秒内，如果同一个 IP 命中 5 次过滤规则，就触发封禁。bantime = 3600：封禁 3600 秒，也就是 1 小时。action = iptables-multiport：通过 iptables 封禁该 IP 对 HTTP/HTTPS 端口的访问。
启动和检查命令：
systemctl restart fail2ban fail2ban-client status ai-bot-scan需要注意的是，fail2ban 的正则要和你实际日志格式完全匹配，否则规则不会生效。写完后可以先跑一条测试日志确认匹配情况，最稳妥的方式是在测试环境构造不同 UA 和路径组合，观察是否被正确封禁。
7.2 在 Cloudflare 等 CDN/WAF 侧联动
如果你的站点前置了 Cloudflare 或其他云 WAF，建议把防护分成两层：源站做路径兜底，CDN/WAF 做行为识别和挑战。
如果你用的是 Cloudflare，在后台进入 Security → Bots 页面，可以看到 Bot Fight Mode 或 Bot Management 设置。免费版可以开启 Bot Fight Mode，但要注意它的拦截逻辑比较粗暴，可能会把部分带自动化特征的正常请求也挡掉。如果你的套餐包含 Bot Management，不建议一开始就调到“严格”模式，更稳妥的是先设为“挑战”或“监控”，让真实 AI 爬虫能够通过验证，同时对明显可疑的请求发起挑战页面。
更精细的做法是使用 WAF 自定义规则，设置两个条件：
- 请求 UA 包含
ClaudeBot、GPTBot等 AI 爬虫标记； - 请求路径匹配
/.env、/.git、/config.php.bak、/wp-login.php等敏感文件。
当两个条件同时满足时，执行“阻止”操作。这样既不会误伤正常 AI 爬虫，又能精准拦截伪装扫描。
7.3 白名单与人工复核
自动封禁有一定概率误伤真实 AI 爬虫，尤其是当你手动维护的 IP 网段不完整时。因此建议在 fail2ban 和 WAF 规则中都预留白名单机制：
- 在 fail2ban 的
ignoreip中写入你确认过的 AI 厂商官方网段。 - 在 Nginx 的
geo变量中维护一份真实 AI 爬虫 IP 列表。 - 封禁动作触发后，定期查看
fail2ban-client status ai-bot-scan，确认封禁的 IP 是否有明显误伤。
人工复核的频率取决于业务规模。如果封禁列表里出现了大厂 IP 或你业务的重要访问来源，就要及时调整白名单和匹配规则。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 日志里看到大量 ClaudeBot 请求文章页 | UA 合法，路径正常，可能是真实 AI 爬虫 | 查看 IP 是否在官方网段、请求频率是否稳定 | 保持观察，必要时按限流策略限制频率 |
| 封禁 AI 爬虫 UA 后搜索收录下降 | 搜索引擎或 AI 爬虫的正常抓取被误拦 | 对比封禁前后日志和收录数据 | 将官方 IP 网段加入白名单，改用 UA + 路径组合规则 |
| Nginx 配置变更后业务异常 | 正则匹配范围过宽，误伤正常 URL | 查看 error.log、检查location优先级 | 收紧正则，先只匹配明确敏感路径 |
| fail2ban 封禁了正常 IP | 过滤正则过宽，或日志字段解析有误 | 执行fail2ban-client status查看匹配记录 | 调整 filter 正则，增加 UA 与路径组合条件 |
| 限流触发 503，正常用户无法访问 | 限流阈值设置过低 | 查看 503 出现的时间段与业务请求量 | 提高阈值，或对静态资源放行 |
| 攻击者换了新的 UA，原有规则失效 | 规则只看 UA，没有看路径和行为 | 统计新 UA 的请求路径，确认是否仍为扫描行为 | 坚持“敏感路径无条件拒绝”策略，减少对 UA 的依赖 |
| WAF 严格模式拦截了正常 AI 抓取 | Bot 管理级别设置过严 | 在 WAF 后台查看被拦截请求的详情 | 将模式改为挑战或监控，并补充白名单 |
9. 防护最佳实践与检查清单
9.1 核心原则
第一，永远不要只依赖 UA 判断流量是否可信。UA 是客户端随手就能伪造的字段，必须结合路径、频率、IP 来源、行为模式综合判断。
第二，先监测，再封禁。看到可疑日志时，先完成 24 到 48 小时的行为观察，确认攻击特征后再落地封禁规则。直接封禁容易造成误伤，而且可能在攻击者换一个 UA 后再次失守。
第三，敏感路径做无差别拒绝。无论请求来自搜索引擎、AI 爬虫还是普通用户，/.env、/.git、备份文件、配置文件这类路径本来就不应该对公网开放，直接返回 403 是最稳妥的。
第四，自动封禁一定要可回滚。fail2ban、WAF 规则、Nginx 黑名单，每一条变更都要有备份、测试和回滚方案。生产环境变更前，确认没有影响正常业务之后再固化。
第五，日志是安全审计的基础。建议合理配置 access.log 的保留周期，重要攻击行为可以通过独立的日志文件或日志采集系统留存，方便后续溯源和复盘。
9.2 检查清单
这套检查清单适合在发现可疑扫描后快速执行：
- 导出最近 24 小时 access.log 中访问过敏感路径的 IP 列表；
- 统计这些 IP 的 UA 分布和请求路径分布；
- 核对 UA 是否为 AI 厂商官方 UA，IP 是否在官方网段；
- 在 Nginx 层添加或确认敏感路径无条件拒绝规则；
- 配置 fail2ban 对“UA + 敏感路径 + 频率”组合进行自动封禁；
- 在 CDN/WAF 后台调整 Bot 管理级别，优先使用挑战而非直接阻止；
- 备份配置，执行
nginx -t，在低峰期灰度发布； - 观察 24 小时，确认没有误伤正常用户和真实爬虫。
下一次，当你再看到访问日志里出现 ClaudeBot 时，别急着放行，也别急着封禁。先问三个问题：它的 UA 是否和官方一致？它的 IP 是否在官方公告网段？它请求的路径是否是一个内容爬虫根本不会碰的文件？答案不同，处理方式天差地别。
AI 爬虫时代的安全运维，考验的不是你会不会封 IP，而是你能不能在一堆“正常流量”里识别出异常行为的痕迹。把日志保存好、把敏感路径看住、把自动封禁设计成可以回滚的机制，就已经赢了一半。
