入口页铺出去以后，很多问题并不是出在链接本身，而是出在蜘蛛集中回来的那几分钟。平时访问量很小，蜘蛛一来就是几十上百个并发请求，服务器最先撑不住的往往不是 CPU，也不是硬盘，而是连接数和出口带宽。
先分清：并发、连接数与带宽是三件事
把它们混在一起谈，很容易调错方向。
- 并发数：同一时刻正在处理的请求数量。它受限于进程/线程模型、数据库连接池、后端接口的处理耗时。
- 连接数：包括服务器自身的连接上限、Web 服务配置里的最大连接数，以及中间的防火墙、负载均衡、CDN 回源连接上限。
- 出口带宽：入口页本身通常很小，但如果每个页面都带上图片、CSS、JS，蜘蛛顺着抓下去，出口流量会被放大好几倍。
三者中任意一个先到顶，表现都像是“蜘蛛抓不动了”，但解决方式完全不同。
蜘蛛集中抓取时常见的几种表现
- 日志里请求时间高度集中，几秒内出现大量相同 IP 段的记录。
- 部分请求返回 502、503、504，而不是 404 或 200。
- 日志出现“连接被重置”“读取超时”，蜘蛛侧看到的是抓取中断。
- 整体响应变慢，TTFB 从几十毫秒涨到几百毫秒以上。
- 静态资源请求大量堆积，正文页反而被挤在后面。
这些现象里，5xx 和连接重置是明确的信号：服务器这端没接住，而不是蜘蛛不想抓。
排查时建议按这个顺序看
- 先看这段时间的整体请求量峰值，确认是不是集中爆发，而不是持续高位。
- 再看服务器监控里的连接数曲线，判断是连接打满还是 CPU 打满。
- 然后看出口带宽占用，尤其是带图片和脚本的入口页。
- 最后看单个请求的处理耗时，确认是后端慢还是网络慢。
按这个顺序走，通常能在一两轮里定位到具体是哪一层先到顶。
常用的缓解手段
- 入口页尽量做成静态或可缓存的页面，减少每次请求都查库、渲染。
- 把不必要的大图、第三方脚本从入口页上撤掉，减少单次抓取的资源开销。
- 对同一 IP 段设置合理的并发上限，让蜘蛛排队而不是一次性涌进来。
- 把入口页放到配置更充裕的机器或节点上，不要和主站业务抢同一份资源。
- 在日志里单独标记蜘蛛请求，方便事后统计峰值时段和来源分布。
不要一边持续扩大入口页规模，一边指望服务器靠运气扛住峰值。规模上去之后，峰值一定会跟着上去。
几个容易踩的误区
- 看到 5xx 就先去加机器，结果瓶颈其实在出口带宽，加机器没有明显改善。
- 把入口页和数据库、后端服务放在同一台机器上，蜘蛛一集中，业务也跟着慢。
- 只盯着入口页大小，忽略了它带出来的静态资源请求。
- 把限速做得太狠，蜘蛛来过一次就长时间不再回来，反而影响 URL 发现节奏。
一些使用建议
入口页的规模不用一次铺到最大，可以先小批量上线，观察被抓取时的峰值曲线，再决定加到什么程度。同时把并发上限、缓存策略、静态资源精简这几件事当成基础设施来做，而不是等出问题再补。服务器端的承载能力始终是有上限的，能不能接住蜘蛛的集中访问，比铺了多少个入口更值得先弄清楚。