很多站长第一次在服务器日志里看到蜘蛛时，会发现它并不是一条一条慢慢来的。同一秒里可能出现好几个请求，分布在不同目录或不同页面上。这并不是蜘蛛“乱抓”，而是抓取端在按自己的并发和速率安排工作。

理解蜘蛛的并发连接和抓取速率，有助于判断服务器该以什么状态回应。如果服务器长期响应慢、频繁超时，蜘蛛通常会降低抓取频率；如果服务器稳定，蜘蛛在预算允许时会更顺畅地走完内链和 Sitemap 里的地址。

日志里能看到哪些并发线索

最直接的观察方法是看访问日志的时间戳。按秒统计蜘蛛的请求数量，如果某一秒出现 3 到 10 个请求，说明抓取端在并行打开连接。不同搜索引擎的并发策略不同，同一个搜索引擎在不同站点上的表现也可能变化。

• 同秒请求数：反映瞬时并发，不等于长期抓取速率。
• 请求间隔：同一 URL 或同一目录的两次抓取之间隔了多久。
• 响应时间：服务器从收到请求到返回首字节的耗时。
• 状态码分布：200、301、404、429、503 的比例变化。

把这些数据放在一起看，比只看总请求数更有意义。比如并发不高但响应时间持续超过一两秒，蜘蛛可能会主动放缓；反过来，响应很快、状态码稳定，蜘蛛在同一时间段内的抓取量往往会更接近站点可承受的上限。

服务器限流与状态码的配合

如果服务器承载有限，不建议直接封禁蜘蛛 IP。更常见的做法是通过状态码表达“现在忙，稍后再来”。

429 与 503 的区别

429 通常表示请求过多，503 表示服务暂时不可用。蜘蛛对这两类状态码一般会做退避处理，也就是降低后续请求频率，过一段时间再尝试。关键在于不要长期返回 429 或 503，否则抓取端可能认为站点持续不稳定，减少来访。

限流的目标是保护服务器，而不是把蜘蛛赶走。短暂、有规律的退避，比长时间无响应更容易让抓取恢复正常。

如果使用 CDN 或反向代理，还要确认限流规则没有把蜘蛛请求误判为攻击流量。有的防护策略会拦截高频 UA 或空 Referer 请求，而蜘蛛请求恰好可能缺少 Referer。检查拦截日志时，可以先把蜘蛛 IP 段和 UA 加入观察名单，再决定是否放行。

robots.txt 里的抓取设置

robots.txt 中的 crawl-delay 并不是所有搜索引擎都支持。Google 明确不遵循该指令，Bing 等部分抓取端会参考。因此，写 crawl-delay 只能作为辅助手段，不能替代服务器端的稳定性和合理的响应速度。

• 如果站点规模小、服务器弱，可以设置一个较大的 crawl-delay，但不要指望所有蜘蛛都遵守。
• 更可靠的方式是让页面快速返回，减少动态渲染和阻塞资源带来的等待。
• 把重要目录的内链和 Sitemap 维护好，让蜘蛛在有限访问次数里优先走到有效页面。

抓取速率与站点结构的关系

蜘蛛愿意抓多少，除了看服务器，也看它发现地址的效率。内链清晰、Sitemap 更新及时、URL 不重复，蜘蛛就不容易把访问次数浪费在重定向链、参数页或空页面上。抓取速率并不是越高越好，而是与站点能稳定提供的有效页面数量匹配。

定期从日志里抽样一周或一个月的蜘蛛请求，记录响应时间的中位数、5xx 占比和 429 出现次数。如果这些指标稳定，抓取节奏通常也会比较平稳。若某段时间蜘蛛来访明显减少，可以先查服务器是否出现过长时间超时或大面积错误，再回头检查内链和 Sitemap 有没有断档。

简单说，蜘蛛的并发和速率是抓取端根据站点反馈动态调整的结果。服务器稳定、响应快速、状态码清楚，蜘蛛就更容易按正常节奏完成 URL 发现和抓取；反之，过载、误封或长期错误会让抓取变慢，甚至让一部分地址迟迟等不到访问。