最近不少运维和安全同学在日志里看到了同一种异常User-Agent 写着 ClaudeBot 的请求并没有按 AI 爬虫的正常方式访问页面而是满屏扫描 .env、/wp-login.php、/config/、/.git 这类敏感路径频率高、规律乱大量 404 也不停手。把 UA 标记成 AI Bot本质上就是一种伪装——攻击者在借“AI 爬虫”这层信任外衣跑大规模漏洞扫描。我按防守视角拆三块来聊攻击者为什么要冒充 AI 机器人日志里哪些特征说明流量不可信从日志、nginx 到 WAF 的排查、限流和封禁顺序最后是几个常见的判断误区。运维、安全工程师以及自己维护站点并经常被扫描骚扰的同学可以拿着日志直接对照操作。1. 为什么攻击者要冒充 AI 机器人1.1 AI 爬虫的 UA 本身就是一张“通行证”现在很多站点的访问控制和反爬策略第一道判断仍然是看 User-Agent。这个字段简单、直观、性能开销低所以被大量使用。而 ClaudeBot、GPTBot、CCBot 这类 AI 爬虫因为承担着采集公开网页内容的任务很多站点会专门把它们放进放行名单甚至通过 robots.txt 明确允许访问。问题就在这UA 只是一个可以被任意修改的字符串。任何人用脚本、命令行工具、开源框架都能把 UA 改成 “ClaudeBot”。如果网站的访问控制逻辑是“只要是 AI Bot 就放行”攻击者只需要改一行 UA就能让自己的扫描流量从“可疑流量”变成“预放行流量”。这也是为什么不能简单说“把 AI Bot 加进黑名单就完事”。真正的关键不是这串字符串叫什么而是你这套信任体系能不能承受一个字段被伪造的代价。1.2 伪装能带来三类实际收益第一绕过简单的 UA 拦截。很多防火墙、WAF 规则会直接拦截空 UA 和常见扫描器 UA但不会拦 AI Bot UA。攻击者等于拿到了一张免费通行证。第二降低告警优先级。安全运营团队每天要处理的告警很多不可避免会做优先级排序。如果扫描流量伪装成正常的 AI 抓取误报率会明显上升真正值得关注的攻击行为反而可能被淹没。第三干扰溯源。流量一旦带上 ClaudeBot 这类字样最初的排查方向很容易被带偏——要么怀疑 AI 厂商要么怀疑某个知名爬虫服务商。攻击者要的就是这种混乱混乱会延长处置时间。1.3 核心问题出在信任模型需要明确一点ClaudeBot 是 Anthropic 官方爬虫的标识它采集公开网页内容的行为本身是正常的。当前这个现象的本质不是“AI 厂商干了坏事”而是“攻击者假冒了 AI 厂商的标识”。所以防守思路要跟着调整不能因为 UA 像官方爬虫就完全信任而要把“UA 声明自己是谁”和“这个来源 IP 是否与官方信息一致”分开看。换句话说信任不能只建立在身份声明上还要建立在来源和行为的一致性上。2. 哪些特征说明扫描流量经过了伪装2.1 先看行为再看声明判断伪装流量最有效的方法是先看行为再看 UA 声明。正常 AI 爬虫通常会访问首页、文章页、栏目页这类实际存在的页面频率相对平稳也会遵守站点给出的抓取规则。伪装扫描流量则完全不同请求路径高度集中在敏感文件上访问规律没有连贯的抓取路径大量 404 仍然继续说明它根本不关心页面是否存在。下面这张表可以快速对照判断维度正常 AI 爬虫伪装扫描流量请求路径首页、文章页、栏目页等公开页面.env、wp-login.php、config.php、.git、backup 等敏感路径访问频率平滑、相对稳定脉冲式凌晨集中短时间大量请求404 比例较低一般按页面链接抓取很高脚本在猜目录和文件名来源 IP与官方公布范围或知名机房一致家宽、小 IDC、境外不常见机房频繁轮换行为逻辑顺着页面链接抓取直接猜路径无抓取逻辑我一般判断的第一步不是看 UA 叫什么而是看“这个 UA 下的行为是不是这个 UA 该有的行为”。如果 UA 说自己是个爬虫却在高频访问登录入口和配置文件那这串 UA 大概率不可信。2.2 IP 归属地和官方信息对不上主流 AI 爬虫机构通常会在官网、robots.txt 或者用户代理说明文档里公布自己的 UA 标识和识别方式部分厂商还会提供 IP 范围或 ASN 信息。没有提供 IP 段的就结合来源归属、机房类型和历史信誉来判断。排查时可以用 whois 查一下实际来源whois 203.0.113.10如果 UA 写的是 ClaudeBot来源 IP 却是境外小机房、家宽段或者是经常被用于扫描的 IDC 网段基本可以判定为伪造。单一特征可能有误差但结合行为路径和频率可信度已经很高。2.3 Header 和指纹细节对不上除了 UA正规爬虫框架发出的 HTTP 请求通常有比较固定的整体特征。伪装流量常见的问题包括Header 顺序与正规框架不一致Accept、Accept-Language、Connection 等字段组合不合理某些扫描工具保留了默认请求头只是替换了 UA导致整体观感很别扭。如果条件允许可以看 TLS 指纹。同一套工具打出的流量即使 UA 每次都不一样TLS 指纹往往是同一个或同一簇这个特征比 UA 难改得多。对普通站点来说可能没有专门的指纹检测能力但也要知道这层维度存在不要因为“Header 看起来完整”就放松警惕。2.4 时间分布和流量曲线异常正常 AI 爬虫的抓取是持续的、平滑的白天晚上都会有速率波动不会特别大。伪装扫描流量往往呈现脉冲式某天凌晨突然来一波高峰扫一两个小时就消失过几天再来或者用固定 IP 池轮换每个 IP 扫一会儿就换下一个。如果你发现某个“AI Bot UA”的访问曲线像心电图一样一高一低、半夜频繁爆发背后大概率不是官方爬虫而是批量调度任务。3. 实际排查流程从日志到限流到封禁3.1 第一步确认日志里到底有什么动手拦截之前先把原始请求拉出来看。以 nginx 默认 access log 为例先按 UA 过滤grep -i ClaudeBot /var/log/nginx/access.log | head -50重点看四个字段来源 IP、请求路径、状态码、访问时间。如果里面出现大量 /.env、/wp-login.php、/config.php状态码成片 404同时还在不断尝试说明这批请求不是正常页面抓取而是扫描行为。这里有个容易忽略的点先确认日志文件路径和格式。很多系统日志路径不同nginx 也可能自定义了 log_format字段顺序和默认格式不一样。如果直接拿固定字段位置去分析统计结果会出错。日志被压缩过的话先解压再查zcat /var/log/nginx/access.log.1.gz | grep -i ClaudeBot | head -503.2 第二步按 IP 聚合看频率和路径几十条样本不够要把“同一个 UA 下到底哪些 IP 在访问、每个 IP 访问了哪些路径”统计出来grep -i ClaudeBot /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -rn | head -20这条命令里$1是默认日志格式的客户端 IP。再统计访问路径grep -i ClaudeBot /var/log/nginx/access.log | awk {print $7} | sort | uniq -c | sort -rn | head -30$7在默认格式下通常是请求路径和参数。两条命令跑完你可以快速看出是大量 IP 共用同一个 UA 扫敏感路径还是只有极少数 IP 在抓正常页面。前者就是要重点处理的伪装扫描。3.3 第三步核对 IP别急着封拿到可疑 IP 列表后先核对再决定封不封。用 whois 或 IP 情报库查归属同时到 AI 爬虫官方页面确认它公布的类型和来源范围。如果官方明确表示只从特定范围发起而日志里的 IP 完全不在范围内基本可以确认 UA 是伪造的。建议把核对结果记录成一张临时清单包含日期、IP、UA、路径、请求数、判断结论。这类记录在后续向云服务商提交封禁、提交威胁情报时非常有用别等需要的时候再翻日志。3.4 第四步先限流再封禁对伪装扫描我的建议是“先限流再封禁”避免一次性误伤正常访问。直接封 IP 适合已经确认恶意的情况如果只是高度疑似先用限流把频率压下去继续观察。nginx 限流示例限制单个 IP 每秒最多 2 个请求limit_req_zone $binary_remote_addr zoneai_scan:10m rate2r/s; server { listen 80; server_name example.com; location / { limit_req zoneai_scan burst10 nodelay; proxy_pass http://backend; } }如果想把敏感路径单独处理可以对特定 URL 做 location 并单独限流或直接拒绝location ~ ^/(\.env|wp-login\.php|\.git|config\.php) { return 444; }返回 444 是 nginx 直接断开连接不回响应比 403 更省资源适合用在已经确认恶意的路径上。但要注意上线规则前先用日志统计确认这些路径确实没有正常访问否则容易误伤。如果流量前面还有云 WAF 或 CDN优先在 WAF 层做路径和频率规则让恶意流量挡在源站之前效果会更好。对已经确认恶意的来源 IP可以用 fail2ban 或云防火墙自动化封禁fail2ban-client set nginx-ai-scan banip 203.0.113.10注意不同版本的 fail2ban 命令略有差异低版本可能需要手动添加防火墙规则使用时先确认当前版本支持情况。3.5 第五步固化成持续监控和告警单次清理干净不代表结束这种批量扫描经常换 IP 池卷土重来。所以要把识别规则固化成监控项。建议关注三个维度访问量维度某个 UA 标识下单个 IP 的小时请求数是否超过阈值比如 1000 次/小时。路径维度对 /.env、/wp-login.php、/.git、/config.php 等敏感路径的请求数按小时聚合。成功率维度某个 UA 对应的 4xx/5xx 比例是否异常升高特别是大量 404 还持续访问。实现方式可以从最简单的 cron 脚本加邮件通知到接入 ELK、云日志服务告警都行。关键是阈值不要拍脑袋定太大否则扫描已经跑完一轮你才收到告警。建议按自己站点正常流量的 3 到 5 倍设定然后根据误报情况逐步调整。4. 几个容易踩坑的判断误区与边界4.1 别把 AI Bot 一刀切禁掉看到这波伪装流量很多人第一反应是“把所有 AI Bot 全禁了”。对纯内网系统这没毛病但对依赖搜索和 AI 收录的公开站点代价很大。AI 搜索、知识库、内容平台的爬虫如果被禁直接影响内容收录和曝光。更合理的做法是分层处理官方公布的来源范围内放行UA 像 AI Bot 但来源不在官方范围内的走验证码或限速行为明显像扫描的直接拦截。三层规则既保留正常爬虫的价值又能拦住伪装流量。4.2 UA 不能作为唯一判断依据这个点值得反复强调UA 是所有 HTTP 头里最容易伪造的字段任何人都能改。只凭 UA 做访问控制本质上是在信任一句自报家门。真正有效的判断永远是组合判断UA 来源 IP 行为路径 访问频率 TLS 指纹。其中任何单一维度都可能误判但多个维度同时异常可信度就非常高。4.3 扫描不等于攻击成功很多运维看到日志里大量 404 和敏感路径就开始紧张。这里要分清楚扫描只是探测行为绝大多数扫描请求不会直接产生危害真正危险的是后续的利用尝试。看到扫描不要慌先识别再拦截然后重点观察有没有人跟进尝试登录、上传、命令执行等行为。只要日志保留得够久后续真出了问题也能还原完整访问链路。不要在扫描阶段耗尽全部精力要始终保持优先级判断。4.4 日志留存是排查的命门所有排查都依赖日志。如果 access log 只保留几天等发现问题再回溯源头早就没了。建议公网服务至少保留 30 天原始日志重要系统保留 90 天以上有条件的把日志实时同步到对象存储或日志平台。同时确认日志轮转策略真实生效有些系统配置了保留策略却没执行等真出事才发现日志早就清理干净了。4.5 公开文章的边界最后说一句实在话公开文章里能给出的是排查思路和规则框架具体到你站点的拦截策略不应该完全照搬。每个站点的正常流量模型、业务路径、允许访问的来源都不一样规则要基于自己的日志数据调整。盲目复制别人的封禁规则很容易误伤自己的正常用户。这波伪装扫描说到底不是新攻击手法而是把“AI 爬虫”这张信任名片用在了错误的地方。只要把身份声明、来源核验和行为监控组合起来就能在它碰触到真实业务之前把它挡在门外。