站点运营

站点运营:抓取被挡住时,先查防火墙、CDN 与维护窗口

搜索蜘蛛抓不到页面,未必是内容和链接的问题。WAF 规则、CDN 的机器人管理、频率限制,以及计划内的维护窗口,都可能让请求在到达源站前就被拦掉。本文按排查顺序梳理常见拦截来源、日志自查方法,以及降低误伤的处理思路。

站点运营

站点运营:抓取被挡住时,先查防火墙、CDN 与维护窗口

先分清是“进不来”还是“进来了没抓”

站点运营中遇到抓取量下滑,很多人的第一反应是内容不够、内链太少。但排查顺序里更靠前的一步,其实是确认蜘蛛的请求有没有真正到达服务器。如果请求在边缘节点或防火墙那一层就被挡掉,后面关于内容质量、栏目结构、更新节奏的讨论都没有意义。

判断方法不复杂:打开访问日志,按蜘蛛的 UA 和来源 IP 段筛选,看最近几天有没有对应记录,以及返回的状态码是什么。403、429、503 这类状态码集中出现,通常说明问题出在“放行”环节,而不是内容环节。

常见的几类拦截来源

WAF 与安全规则

安全防护默认是宁可错杀,这对正常访客影响不大,对蜘蛛却可能是致命的。容易被忽略的几种情况:

  • 规则误伤:URL 带较长查询参数、含特殊字符,或路径形似注入语句时被直接拦下;
  • 频率阈值:单位时间内同一 IP 请求数过多,触发限速,返回 429;
  • UA 黑名单:早期为了挡采集加的规则,后来把搜索蜘蛛一起挡住了;
  • 地域限制:只对特定地区开放,而蜘蛛节点恰好不在放行范围内。

CDN 与云防护的机器人管理

不少 CDN 默认开启了机器人识别与人机校验,普通访客看到的是一个验证页,蜘蛛看到的可能是 403 或一段空的 JS 页面。这类拦截在日志里往往表现为状态码正常、但响应体很小、内容为空,需要抓包或直接模拟请求才能看出来。

源站侧的连接限制

除了安全层,源站自身也可能成为瓶颈:连接数上限偏低、Keep-Alive 配置过短、并发线程不足,都会让并发抓取变成大量超时。这类问题在高频抓取时更明显。

维护窗口与计划内变更

运维动作对抓取的影响经常被低估。下面这些场景里,蜘蛛拿到的不是内容,而是一次失败请求:

  • DNS 切换后 TTL 尚未过期,新旧解析并存,部分请求打到已经停止服务的旧 IP;
  • 证书过期或配置错误,TLS 握手失败,连接根本建立不起来;
  • 迁移期间只留了内网入口或临时提示页,外部访问直接返回 502、503;
  • 数据库备份、全量重建索引占满资源,响应时间被拉长到超时。
维护本身不是问题,问题在于维护期间正好有一批新 URL 上线,却没有任何一个爬虫能访问到它们。

减少误伤的几个处理思路

  1. 先验证再放行。对声称是搜索蜘蛛的请求做来源验证,比如反向 DNS 解析,确认后再加入白名单,比直接按 UA 字符串放行可靠得多。
  2. 把重要路径单独加规则。站点地图、列表页、详情页这类需要被发现的路径,可以从严格的频控策略里排除。
  3. 维护时间避开内容发布。大版本发布、栏目调整尽量安排在流量低峰,并保证维护期间返回的是明确的 503 加 Retry-After,而不是空白页。
  4. 变更后做一次可用性回归。用不带 Cookie、不带登录态的请求,从外部网络访问几个关键 URL,确认状态码与内容都正常。
  5. 订阅证书与域名到期提醒。这类故障没有征兆,但影响范围往往最大。

把“可访问性”当成日常指标

抓取量、状态码分布、响应时间,这几项数据放在一起看,比单看收录数字更能说明问题。蜘蛛能稳定地进来、拿到完整内容,是所有 URL 发现手段的前提。安全策略、CDN 配置和运维计划各自独立,但它们共同决定了这个前提是否成立,值得在站点运营的例行检查里占一个固定位置。