聊抓取时，大家习惯盯着“蜘蛛今天来了几次”“抓了多少个页面”，却很少问一个更底层的问题：它同时开了几条连接。这件事直接决定了 URL 被发现的速度，也决定了服务器在某一秒钟要承受多大的压力。
抓取不是一条线在走
蜘蛛对同一个站点的抓取通常是并发的：同一时间可能有几个到十几个请求同时打进来，分散在不同的 URL 上。所以你在日志里经常看到同一秒出现好几条记录，时间戳互相重叠。并发数高，新链接被发现得快；并发数被压得很低，新 URL 就只能慢慢排队，Sitemap 里的条目也要等更久才轮到。
并发数由哪些因素决定
- 站点响应速度：响应越快，搜索引擎越愿意提高并发；慢站点会被自动降速。
- 历史抓取表现：长期稳定、错误少的站点，抓取节奏更从容。
- 错误率：5xx、超时、连接被重置，都会让并发被主动压低。
- 站点规模与更新频率：内容多、更新勤的站点，抓取需求更大。
- 服务器反馈：明确的限速信号会被参考，但不同引擎的遵循程度不一样。
从日志里看并发
不需要复杂工具，把一天的访问日志按秒切分就能看出大概：
- 同一秒内属于同一来源 IP 的请求条数，近似等于当时的并发量。
- 响应时间的中位数和长尾值，长尾越长，并发越容易被拖下来。
- 5xx 与 429 的占比，比例升高往往意味着服务器在主动拒绝。
- 限速前后抓取条数的变化，能反推你对并发的干预是否过头。
连接复用比一次次新建更划算
如果每个请求都重新握手，蜘蛛和服务器都要付出额外开销：TCP 三次握手、TLS 协商、线程创建。开启 Keep-Alive 或使用 HTTP/2 的多路复用后，同一条连接可以承载多个请求，抓取吞吐会更平稳。所以服务器上的连接空闲超时不要设得太短，否则蜘蛛刚建立好的连接很快被断开，它只能反复重连，你也会在日志里看到大量短连接。
服务器端该怎么配合
- 保证稳定响应，避免请求长时间挂起不返回。
- 需要降速时，用 503 加 Retry-After 告诉对方稍后再来，而不是直接封 IP。
- 把图片、脚本等静态资源交给 CDN，把并发额度留给 HTML。
- 用 DNS 回查确认来源，别把真蜘蛛和假蜘蛛一起挡在门外。
- 盯着并发峰值与数据库连接数，避免首页或列表页被拖垮。
限速不会让蜘蛛消失，只会让 URL 发现变慢。如果你的站点每天都有新页面需要被发现，过度限速就等于把它们按在队尾。
一份简单的自检清单
- 取一周日志，统计每日同一秒的最大并发与平均值。
- 对比响应时间曲线与抓取条数曲线，看是否此消彼长。
- 确认 Sitemap 的获取间隔是否被明显拉长。
- 抽查新发布页面的首次被抓时间，是否比一个月前变慢。
- 检查是否有连接被服务端提前关闭的情况。
并发连接是个双向指标：它既是蜘蛛对站点的信任度，也是服务器能不能接得住的考验。把响应做稳、把错误率压下去、把降速方式换成温和的 503，抓取节奏自然会回到一个双方都舒服的位置。