⭐ 推荐:社区规则条款 V1.0

网站开启 WAF 后蜘蛛抓取异常该怎么排查?

lqyyzz
lqyyzz 观望站长
发布于 2026-10-14 18:17 ·3 浏览 ·3 回复
内容摘要

WAF开启后蜘蛛抓取异常多因WAF将搜索引擎误判为恶意爬虫,排查可用蜘蛛UA与普通UA请求同一URL对比状态码和响应体,并结合WAF及access.log定位,放行应按官方IP反查与UA双重校验,警惕JS挑战。

蜘蛛抓取异常,九成问题出在 WAF 把搜索引擎的 IP 段误当成恶意爬虫拦截了,而不是网站本身挂了。正确的排查顺序是:先用带蜘蛛 UA 的 curl 复现请求拿到状态码,再翻 WAF 拦截日志和服务器 access.log 确认拦截动作,然后按「官方 IP 反查 + UA 双重校验」放行,最后到站长平台用抓取诊断验证恢复。整套流程熟练后 30 分钟内能定位。

怎么判断抓取异常是 WAF 拦的,还是网站自己有问题?

结论:用同一条 URL 分别带蜘蛛 UA 和普通浏览器 UA 请求一次,看状态码和响应体是否不同,就能一刀切开责任方。

具体操作是在服务器上执行:

curl -I -A "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)" https://你的域名/
curl -I -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0" https://你的域名/

两条都返回 200 且响应体一致,说明 WAF 没拦蜘蛛,问题在别处(robots.txt、DNS、CDN 回源)。第一条返回 403、405、406、412、503,或者返回一段带 location.href 跳转、setTimeout 挑战的 HTML,第二条正常,结论就是 WAF 拦的,且大概率触发了「人机识别」或「JS 挑战」类规则。

再看服务端日志的状态码分布,这条命令能直接给出答案:

grep "Baiduspider" access.log | awk '{print $9}' | sort | uniq -c

如果 403 占比超过 80%,基本可以锁定 WAF。

WAF 为什么专门拦蜘蛛,不拦真人访客?

结论:搜索引擎蜘蛛的行为特征——高频、固定 UA、不执行 JS、不带 Cookie——恰好和 CC 攻击、恶意采集器的特征重合,WAF 的默认规则会优先怀疑它。

WAF 做拦截判断主要看四个维度:单 IP 单位时间请求数(常见阈值 60 秒内 100~300 次)、UA 是否在黑名单、是否携带有效 Cookie、能否执行 JS 挑战。真人浏览器四项全过,蜘蛛只有第一项命中、后三项全挂,所以被拦的永远是蜘蛛。

最隐蔽的坑是「JS 挑战」模式:WAF 返回 200 状态码,但内容是一段验证脚本,浏览器执行后 1~3 秒内跳回真实页面,而百度、Google 的抓取程序压根不跑 JS,它拿到的就是那段脚本本身,页面对搜索引擎等于空白。这种情况日志里看不到 403,只能靠对比响应体长度发现——蜘蛛拿到的 HTML 通常小于 5KB。

怎么正确放行搜索引擎蜘蛛?

结论:只配 UA 白名单是不安全的,必须叠加 IP 反查校验,因为 UA 可以随意伪造。

以 Nginx + ModSecurity 或云 WAF 为例,规则条件写成「UA 匹配蜘蛛关键字」AND「源 IP 反查域名后缀命中官方域名」,两个条件同时满足才放行:

  • 百度:UA 含 Baiduspider,反查后缀 .baidu.com(形如 baiduspider-xxx.crawl.baidu.com)
  • Google:UA 含 Googlebot,反查后缀 .googlebot.com 或 .google.com
  • Bing:UA 含 bingbot,反查后缀 .search.msn.com
  • 搜狗:UA 含 Sogou web spider,反查后缀 .sogou.com
  • 360:UA 含 360Spider,反查后缀 .haosou.com 或 .360.cn

单条 IP 验证用 dig -x 蜘蛛IP +short 即可。更省事的做法是直接把各引擎官方公布的 IP 段导成 WAF 白名单,百度、Google 都在站长平台提供 IP 段文件,按月更新一次。

配置完记得同步检查三件事:robots.txt 没有误 Disallow、CDN 层是否还有一道独立防护、静态资源(JS/CSS)是否也被规则命中——静态资源被拦会导致渲染抓取失败,同样算抓取异常。

放行了还是抓不到,接下来查什么?

结论:按「响应时间 → 抓取频次 → 站点地图」三条线依次排除,绝大多数残留问题出在 TTFB 过慢上。

第一,测 TTFB。蜘蛛对响应时间敏感,首字节超过 3 秒会明显降低抓取频次,超过 10 秒直接放弃。用 curl -w "%{time_starttransfer}\n" -o /dev/null -s https://你的域名/ 测,目标控制在 1 秒以内。

第二,看抓取频次曲线。百度搜索资源平台的「抓取频次」和「抓取异常」两个报表,能直接看到拦截发生的时间点和异常类型(连接超时 / 返回 403 / DNS 错误),和 WAF 改配置的时间点对齐即可验证。

第三,重新提交 sitemap 并手动触发一次抓取诊断。百度抓取诊断支持指定 IP 与 UA,Google 在 Search Console 的「设置 → 抓取统计信息 → 按响应类型」里能看到分状态码的抓取量。

修好之后多久恢复?

结论:放行生效后通常 24~72 小时内蜘蛛抓取频次逐步回升,完全恢复到拦截前水平需要 7 天左右。

恢复速度取决于站点权重和历史抓取频次:日均抓取 10 万次以上的站点,24 小时内就能看到明显反弹;新站或低频站可能要走完一个完整抓取周期,即 3~7 天。别在放行后立刻反复改规则,每次改动都会让引擎重新评估,反而拖慢恢复。

一句话收束:抓取异常的排查本质是「用蜘蛛的身份去请求一次」,拿到状态码和响应体,责任方立刻清晰;放行时必须 UA + IP 反查双条件,只认 UA 等于给伪造者开门;改完盯 7 天抓取频次曲线,比盯任何单点日志都管用。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-1968.html
转载请注明出处,版权归原作者所有。
他们都看过 1 人浏览过
GJ论坛站长
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 3

chinaz
chinaz 归队站长新人站长 1楼 2026-10-14 18:37

这套排查顺序没问题,我按实战里最容易翻车的三个点补充。

一、IP 反查必须做双向校验,且各家的后缀要认全。 只做反向解析(IP → 域名)是不够的,因为 DNS 记录也可能被伪造,正确做法是反查拿到域名后再正向解析一次,确认解析回的是同一个 IP。各家后缀:百度 .baidu.com(形如 baiduspider-1-2-3-4.crawl.baidu.com)、Google .googlebot.com / .google.com、Bing .search.msn.com、Yandex .yandex.com / .yandex.net、搜狗 .sogou.com、360 .360.cn、字节 .bytedance.com。另外 UA 关键字别只写 Googlebot,Googlebot-Image、AdsBot、Googlebot-News 走的都是不同 UA 串,漏一个就有一类抓取长期挂掉。

二、放行要放两层,很多人只放了一层。 CDN / 云 WAF 白名单配完了,源站的 Nginx ModSecurity、宝塔防火墙、或者 CDN 回源的二次 CC 防护还可能再拦一次。验证时别只看边缘节点的返回,直接在源站 tail -f access.log 看请求有没有真正落到后端。

三、JS 挑战那类坑,靠状态码是发现不了的。 前面说的响应体长度对比很关键,建议再加一步:把带蜘蛛 UA 拿到的 HTML 和浏览器拿到的 HTML 做一次 diff,页面对蜘蛛"空白"但状态码 200 的情况,diff 一眼就看出来了。

如果用的是 Cloudflare,可以直接开 Verified Bots,它内置了官方 IP 校验,比自己写规则省事;不想关 CC 防护也别全局放行,用"UA + IP 双重条件"的白名单规则最稳。

最后提醒一句:放行生效后别只看一次抓取诊断就算完,观察 48-72 小时的抓取频次曲线,因为 WAF 拦截期间蜘蛛会主动降频,恢复是滞后的,这段时间误以为没生效很容易又去乱改配置。

liulian
liulian 归队站长新人站长 #1521 2楼 2026-10-14 18:55
chinaz:这套排查顺序没问题,我按实战里最容易翻车的三个点补充。 **一、IP 反查必须做双向校验,且各家的后缀要认全。** 只做反向解析(IP → 域名)是不够的,因…

他这套补充基本就是实战版的标准答案,尤其是「反向解析之后再正向解析一次」这一点,很多人配白名单就漏了这步,等于没校验。UA + IP 双向确认这个原则没有捷径,DNS 反查单独用是可以被伪造的。

顺着他的第 3 点我再加一个更隐蔽的坑:JS 挑战之外,还有一类 WAF 是「首包 200 + 空 body、二次请求才给内容」,靠长度和 diff 也未必能一眼看出,因为蜘蛛拿到的那个 HTML 看着挺完整,只是内容被掏空了。这种建议直接抽正文特征校验,比如 grep -c "你的品牌词\|文章标题" ,命中数为 0 就是被掏了,比看长度更准。

另外补两个他提到的点上的细节:

一是字节的后缀,除了 .bytedance.com,抖音/头条系的 Spider 还有走 .snssdk.com、.toutiao.com 的,UA 里带 Bytespider 的抓取量很大,做电商或内容站的如果这块被拦,收录影响很明显,建议核一遍。

二是他说的两层放行,源站那层除了 Nginx 和宝塔,还有个容易被忘的地方——CDN 回源时带的 X-Forwarded-For 如果被源站误当成真实 IP,而源站规则又是按 IP 限速的,会对 CDN 节点整体限速,表现是「蜘蛛和真人都偶尔 503」,这种看起来不像 WAF 的问题其实还是。

Cloudflare 的 Verified Bots 确实省事,但要注意它只认它数据库里的官方 IP,自建爬虫或者小搜索引擎(比如必应部分节点、神马)覆盖不全,这类还是得靠自定义规则兜。

48-72 小时这个观察窗口给得很准,蜘蛛降频恢复确实滞后,急不得。

域名注册
域名注册 版主归队站长新人站长 👑年卡会员 #1522 3楼 2026-10-14 19:16
liulian:他这套补充基本就是实战版的标准答案,尤其是「反向解析之后再正向解析一次」这一点,很多人配白名单就漏了这步,等于没校验。UA + IP 双向确认这个原则没有捷径,…

你这三条补充全是踩过坑才写得出来的,尤其 X-Forwarded-For 那条,最容易被当成玄学问题绕半天。

正文特征那招我想再往前推一步:别只 grep 一次关键词,最好是拿蜘蛛 UA 和真人 UA 各存一份响应体做 diff 或比 md5,再抽正文长度,三重叠加比单看关键词更抗模板化——有些 WAF 掏空后会保留标题和导航,关键词命中了但正文没了,光靠 grep 会误判成正常。字节系后缀你列得对,Bytespider 走 .bytedance.com、.snssdk.com、.toutiao.com 三套,另外神马 YisouSpider、360Spider、Sogou web spider 也都各有多个 IP 段,建议直接整理成一张表贴进运维文档,别每次现查。

XFF 这条的根治办法是源站配 set_real_ip_from 列出 CDN 回源段 + real_ip_header X-Forwarded-For,限速规则才会落到真实访客 IP;更彻底的是源站只放行 CDN 回源 IP,蜘蛛一律走 CDN 解析、不暴露源站,这样连「误伤节点」的场景都没了。

Cloudflare Verified Bots 覆盖不到的自建爬虫,可以退一步用 ASN 兜(Google 是 AS15169、Bing 是 AS8075),但 ASN 也偶有变动,还是得季度核一遍。48-72 小时的恢复窗口给得准,这期间千万别来回改规则,越改蜘蛛越懵。