限流规则把搜索引擎一起挡了：目录站的爬虫白名单该怎么配

目录站的接口被刷是常态：有人拿你的搜索接口当免费查询用，有人遍历条目页抓数据。加限流之后世界清静了，然后某天看 Search Console，抓取量掉下去一截，收录跟着掉。

问题出在判断依据上。限流规则按 IP 和频率走，而爬虫的请求特征跟脚本攻击高度重合：IP 集中、请求密集、UA 还是同一个。

图片来源：网络，版权归原作者所有，侵权请联系删除

UA 这东西谁都能改

先说结论：不能用 UA 放行。UA 是请求方自己填的一行文本，一行 curl 就能伪装成 Googlebot。谷歌自己的文档里也写明了，Googlebot 的 UA 经常被其他爬虫冒用。

正确做法是两步验证。第一步对来源 IP 做反向 DNS 解析，谷歌的主机名应当以 googlebot.com、google.com 或 googleusercontent.com 结尾；第二步拿解析出来的主机名再正向解析一次，回来的 IP 必须和原始 IP 一致。第二步才是关键，只设 PTR 记录谁都能做到，让对方的 DNS 指回自己,做不到。

Bingbot 是同样的流程，主机名结尾换成 search.msn.com。批量处理日志时，用官方发布的 IP 段 JSON 比对更快，但那份清单会变，得定期拉新的缓存。

白名单放在哪一层

典型的三层是 CDN、WAF、应用。放 CDN 层最快也最省事，问题在于 CDN 看到的 IP 是经过了它自己转发的，你要确认拿到的是真实客户端 IP。放应用层最准确，但被限流的请求已经打到后端了，防护效果打折。我的做法是 CDN 层按 UA 做粗筛（放行冒充成本高的那几个），应用层对命中限流的 IP 做一次 DNS 验证，验证通过的放进一个短时白名单。

这个白名单要有过期时间。IP 段是会发生变化的，永久白名单等于给自己埋了个说不清的口子，我一般给 24 小时。

429 和 503 不是一回事

状态码	含义	爬虫会怎么理解	什么时候用
429	请求超配额	慢下来，稍后重试	接口、搜索、提交这类高频端点
503	服务暂时不可用	暂时放弃，过会再来	后端真的撑不住、维护中
403	不允许访问	当这条 URL 不存在处理	确认是恶意流量时

谷歌在《减慢 Google 抓取速度》文档里给的紧急降速办法，是返回 500、503 或 429，可以带 Retry-After 头（RFC 9110 定义），告诉抓取方多久之后再来。注意它同时警告了：这么干不要超过一两天，同一个 URL 连续几天返回这些状态码，可能会被从索引里移除。另外，抓取速度只能往下调，没法申请调高。

所以限流的目标不是让爬虫撞墙，是让它自己慢下来。给爬虫的阈值要单独设一档，比普通用户宽松一些，同时保证真的被打垮时有 503 兜底。

误伤了怎么发现

靠感觉是发现不了的。抓两件事：一是日志里按爬虫 UA 分组统计 4xx/5xx 的比例，这个数平时很低，一旦从百分之一以下跳到两位数，基本就是规则误伤；二是 Search Console 的抓取统计报告，响应时间曲线和抓取量曲线一起看。两条线对不上的时候，八成是限流在起作用。

还有个容易被忽略的点：如果页面用了懒加载或者接口渲染，抓取时触发的请求比用户浏览时更密集，阈值设得太紧，先撞墙的往往是条目页里的动态模块。

日志侧还能看的东西更多，从日志还原蜘蛛走过的路线那篇里，有一套把抓取路径拆开看的现成视角。

限流规则的验收标准应该写进发布流程：上线之后 24 小时内，看一眼爬虫的 4xx 比例有没有变化。这一步花两分钟，能省掉后面一个月的挽回。