蜘蛛池的入口页通常不靠内容取胜，而是靠数量。几百上千个入口页同时在线，蜘蛛一旦顺着链接批量抓取，请求会在很短时间内集中落到同一批服务器上。这一步没准备好，前面做的 URL 设计、锚文本、返回码规划，都可能在前几分钟里被打乱节奏。
并发到底从哪来
不少人把蜘蛛抓取想象成匀速慢爬，实际更接近脉冲式：发现在前，抓取在后，而且往往撞在同一个时间窗里。几个叠加因素会把瞬时请求放大：
- 入口页数量乘以蜘蛛类别数，几十个入口页配上两三个搜索引擎，起点就不低；
- 不同搜索引擎的蜘蛛可能同时工作，高峰互相重叠；
- 入口页之间如果互相内链，蜘蛛一次可以推进多层，请求量成倍增加；
- 同一站群挂在同一台机器或同一 IP 上，等于把所有压力堆在一个出口。
服务器扛不住时会出现什么
最先出现的不是报错，而是变慢：响应时间从几十毫秒涨到几秒。接着才会出现更明确的信号：
- 返回 5xx 或直接超时，蜘蛛记录为抓取失败；
- 连接被重置，握手阶段就中断；
- 蜘蛛主动降低抓取频率，甚至暂停对该主机的抓取一段时间。
需要分清楚：这不是「被抓多了被惩罚」，而是资源不足造成的失败。但结果类似——入口页被蜘蛛看到的次数变少，后续的 URL 发现自然跟着变慢。
上线前可以做的准备
- 入口页尽量静态化，避免每个请求都查数据库、跑模板；
- 打开页面级缓存，设置合理的过期时间，减少重复计算；
- 静态资源与 HTML 分开处理，图片、CSS、JS 交给 CDN 或独立域名；
- 调整 Web 服务器的最大连接数、队列长度与超时时间，别用默认值硬扛；
- 检查数据库连接池和慢查询，很多「服务器慢」其实卡在数据库这一层。
这些措施的目标不是让并发无限大，而是让峰值来的时候不至于大面积失败。
限速是双向的
限速不只是限制别人，也是给自己留余量。robots.txt 里的 crawl-delay 并非所有蜘蛛都尊重，因此更可靠的做法是在服务端按 UA 做分流和限流：对已知蜘蛛的请求单独设置速率，对来源不明的请求做更严格的配额。这样即使某个入口页被集中抓取，也不会把整台机器的资源吃光。
限流要留观察窗口。设置得太紧，蜘蛛拿不到页面，等同于自己放弃了被发现的机会；设置得太松，又回到过载的老问题。通常建议先按当前承载能力的七成来设，再根据日志逐步调整。
几个常见误区
- 并发越大越好：入口页数量增加并不等于抓取量线性增加，服务器先崩反而会让整体效率下降。
- 入口页用动态参数：带参数的地址更容易重复抓取，也会让缓存失效，白白消耗资源。
- 不看日志：状态码分布、平均响应时间、峰值 QPS 这些指标是判断是否需要扩容的直接依据，不看就只能靠猜。
- 所有站点共用一台机器：单点故障之外，还容易让一个站的问题波及全部入口页。
观察与调整的节奏
上线后先看一周日志，重点看三件事：抓取失败率、峰值时段、单个入口页的平均抓取次数。失败率偏高就先查服务器，而不是急着加入口页；峰值时段固定，可以考虑错开内容更新和资源发布的时间；单页抓取次数过低，再回头检查入口页本身的可达性和内链结构。
容量是一步步试出来的，不是一次性配出来的。小步扩容、持续观察，通常比一开始就堆大量入口页更稳妥。
入口页的并发准备，本质上是把「蜘蛛愿不愿意来」的前提条件先补齐。服务器稳定，蜘蛛才可能稳定地来；服务器不稳，再多的入口页也只是增加失败记录。