入口頁铺出去之後，很多人只盯着“蜘蛛来了多少”，忽略了另一件事：蜘蛛的抓取不是匀速的。某些时段它會突然集中訪問同一批 URL，短時間内的並發請求可能比平时高出一個量級。服務器如果没做准备，這段時間會集中出現超时、5xx，甚至被机房临时限速。抓取失敗率一高，後續的訪問节奏往往會變慢，前面铺的工作也就打了折扣。
蜘蛛的抓取為什么會集中
几個常见原因：一是新 URL 被發現後，蜘蛛倾向于在較短時間内先跑一遍，確認頁面能不能訪問；二是入口頁上的連結列表如果更新在同一时刻，蜘蛛會按同样的顺序连續請求；三是多台蜘蛛节点同时工作，你看單條日誌是分散的，但匯總到服務器上就是一波並發。
另外，如果把入口頁部署在同一台机器、同一個 IP 上，所有抓取都會落到同一個出口，压力不會自動分摊。
先看日誌，再决定要不要扩容
不要一上来就加机器。先花一两天把訪問日誌按小时統計一下，重点看：
- 每小时的總請求數，以及其中蜘蛛 UA 的占比
- 同一秒内的最大並發，可以用日誌時間戳粗略估算
- 响應碼分布，5xx 出現在哪些 URL 上
- 平均响應時間，以及最慢的那几個頁面
如果 5xx 只集中在少數動態頁面，問题多半在代碼或資料库，而不是带宽。如果所有頁面都慢，才考虑出口或机器規格。
几個容易被忽略的瓶颈
動態生成與資料库连接
入口頁如果每次請求都查库、拼模板，蜘蛛並發一上来，資料库连接池會先被打满，後面所有請求一起排队。能静態化就静態化，不能静態化的頁面加一层短时缓存，缓存時間不用長，几十秒到几分钟就能挡掉大部分重复請求。
带宽與静態资源
蜘蛛通常不加载图片和脚本，但頁面 HTML 里如果内嵌了大量 base64 图片或超長的内联脚本，單次响應体积會翻好几倍，带宽消耗按請求數成倍放大。把 HTML 控制在合理体积，静態资源外鏈並交给 CDN，是成本最低的一步。
單 IP 的连接數與被防火墙拦截
有些机房或云厂商對單 IP 的入站连接數有預設上限，触發後會直接丢包，表現出来就是“服務器没問题但訪問超时”。上线前問清楚這個限制，必要时和供應商說明會有爬虫訪問。
主動限速比被動超时好
如果服務器規格有限，與其让它在高峰期超时，不如主動控制节奏。常见的做法：
- 對明顯是蜘蛛的 UA 做並發上限，超過就排队，而不是直接拒绝
- 用 429 加 Retry-After 回應超額請求，比返回 5xx 更友好
- 把入口頁的連結列表按批次更新，避免同一时刻全量變動
- 不同入口站分散到不同机器或不同出口 IP
注意限速不要過猛，長期返回 429 也可能让蜘蛛降低訪問频率，具体阈值需要根據自己的日誌反复調。
出現 5xx 之後怎么處理
5xx 不是“重试一下就好”的信号，它通常意味着服務端确實没接住。發現之後先定位是哪些 URL、哪個时段，再决定是修代碼、調缓存還是加资源。短時間内反复出現 5xx 的入口頁，可以考虑先下线修好再恢复，比一直挂着更容易控制影响。
蜘蛛的抓取频率是它自己的判断，你能做的是让服務器在它来訪时稳定應答。承载准备不會直接带来收錄或排名，但能减少“资源到位却抓不動”的浪費。
日常盯的几個指标
- 蜘蛛請求的响應碼分布，尤其是 5xx 比例
- 平均响應時間與 P95 响應時間
- 單机 CPU、内存、資料库连接數峰值
- 出口带宽的日峰值
把這些做成简單的日报或图表，比等到出問题再翻日誌要省事得多。