入口頁铺出去以後，很多問题並不是出在連結本身，而是出在蜘蛛集中回来的那几分钟。平时訪問量很小，蜘蛛一来就是几十上百個並發請求，服務器最先撑不住的往往不是 CPU，也不是硬盘，而是连接數和出口带宽。
先分清：並發、连接數與带宽是三件事
把它們混在一起谈，很容易調错方向。
- 並發數：同一时刻正在處理的請求數量。它受限于進程/线程模型、資料库连接池、後端接口的處理耗时。
- 连接數：包括服務器自身的连接上限、Web 服務配置里的最大连接數，以及中間的防火墙、负载均衡、CDN 回源连接上限。
- 出口带宽：入口頁本身通常很小，但如果每個頁面都带上图片、CSS、JS，蜘蛛顺着抓下去，出口流量會被放大好几倍。
三者中任意一個先到顶，表現都像是“蜘蛛抓不動了”，但解决方式完全不同。
蜘蛛集中抓取时常见的几種表現
- 日誌里請求時間高度集中，几秒内出現大量相同 IP 段的记錄。
- 部分請求返回 502、503、504，而不是 404 或 200。
- 日誌出現“连接被重置”“讀取超时”，蜘蛛侧看到的是抓取中断。
- 整体响應變慢，TTFB 從几十毫秒涨到几百毫秒以上。
- 静態资源請求大量堆积，正文頁反而被挤在後面。
這些現象里，5xx 和连接重置是明确的信号：服務器這端没接住，而不是蜘蛛不想抓。
排查时建议按這個顺序看
- 先看這段時間的整体請求量峰值，確認是不是集中爆發，而不是持續高位。
- 再看服務器监控里的连接數曲线，判断是连接打满還是 CPU 打满。
- 然後看出口带宽占用，尤其是带图片和脚本的入口頁。
- 最後看單個請求的處理耗时，確認是後端慢還是網絡慢。
按這個顺序走，通常能在一两轮里定位到具体是哪一层先到顶。
常用的缓解手段
- 入口頁尽量做成静態或可缓存的頁面，减少每次請求都查库、渲染。
- 把不必要的大图、第三方脚本從入口頁上撤掉，减少單次抓取的资源開销。
- 對同一 IP 段設定合理的並發上限，让蜘蛛排队而不是一次性涌進来。
- 把入口頁放到配置更充裕的机器或节点上，不要和主站业務抢同一份资源。
- 在日誌里單獨标记蜘蛛請求，方便事後統計峰值时段和来源分布。
不要一邊持續扩大入口頁規模，一邊指望服務器靠运气扛住峰值。規模上去之後，峰值一定會跟着上去。
几個容易踩的誤区
- 看到 5xx 就先去加机器，结果瓶颈其實在出口带宽，加机器没有明顯改善。
- 把入口頁和資料库、後端服務放在同一台机器上，蜘蛛一集中，业務也跟着慢。
- 只盯着入口頁大小，忽略了它带出来的静態资源請求。
- 把限速做得太狠，蜘蛛来過一次就長時間不再回来，反而影响 URL 發現节奏。
一些使用建议
入口頁的規模不用一次铺到最大，可以先小批量上线，观察被抓取时的峰值曲线，再决定加到什么程度。同时把並發上限、缓存策略、静態资源精简這几件事当成基础设施来做，而不是等出問题再补。服務器端的承载能力始终是有上限的，能不能接住蜘蛛的集中訪問，比铺了多少個入口更值得先弄清楚。