很多站点在日志里看到蜘蛛的请求，会默认以为它是沿着队列一条一条慢慢爬。实际情况通常不是这样：搜索引擎的抓取端会针对一个站点同时开启若干条连接，把队列里的 URL 并行取回。理解这一点，对判断服务器压力和排查抓取变慢的原因都有帮助。
蜘蛛不是只开一条连接
抓取端会根据站点的整体表现来分配并发规模。响应快、错误率低的站点，往往会被允许更多连接同时进来；反过来，如果超时频繁、5xx 较多，并发会被收缩，抓取速度随之下降。也就是说，并发数不是固定的福利，更像是站点健康度的一个反馈结果。
并发数是怎么变成服务器压力的
可以用一个粗略的换算来理解：并发数乘以单页处理时间，大致对应每秒的请求量。假设蜘蛛在站上维持 5 条并发，每个页面处理 200 毫秒，那么大约是每秒 25 个请求；如果每页要处理 2 秒，每秒只剩 2.5 个请求。有意思的是，后一种情况下服务器虽然被拖慢，蜘蛛抓到的页面反而更少——响应慢并不等于压力小，只是把压力拉长了。
响应变慢之后，抓取节奏会怎么变
单页变慢时，通常先看到的是抓取速率下降，队列里的 URL 等待时间变长。如果慢到触发超时，蜘蛛会中断这次请求，稍后再来；少数几个超时影响不大，但如果超时变成常态，抓取端可能会主动降低并发，甚至把站点标记为慢站，抓取频次随之减少。这个过程往往没有明显提示，只能从日志里的请求数和响应时间看出来。
服务器侧常见的几个坑
- 单页处理时间随并发线性上涨：数据库连接池不够、同步调外部接口，都会让并发一上来就集体变慢。
- 没有开启长连接：每个请求都重新握手，连接开销吃掉大量资源。
- CDN 或 WAF 把蜘蛛的多条连接当成异常流量，返回 403 或验证码，抓取直接中断。
- 服务端渲染的逻辑在请求内同步执行，遇到并发就大面积超时。
- 抓取高峰与真实用户高峰重叠，两边互相拖慢，谁都不满意。
可以做的几件事
- 在日志里按分钟统计蜘蛛请求数，先看清峰值是多少，而不是只看一天的总量。
- 给重要目录单独观察响应时间，先把慢的模板或接口优化掉。
- 让页面主体和静态资源分开处理，避免一个慢接口拖住整个页面的返回。
- 核对 CDN 与 WAF 的爬虫放行规则，确认放行的是真实蜘蛛的 IP 段。
- 服务器确实扛不住时，用 503 配合 Retry-After 明确告知，比让请求挂到超时更友好。
抓取并发更像是结果而不是原因：站点响应越快、错误越少，蜘蛛越敢多开连接。想把抓取做好，先把单页响应时间和错误率降下来，再谈其他。