入口页铺得越多，抓取请求的总量就越大，而这些请求最终都落在同一批服务器上。很多人只盯着“蜘蛛来了多少次”，却忽略了服务器能不能接得住——一旦源站开始变慢、超时、返回 5xx，入口页本身的可抓取性就先垮了。频次控制的目标不是把抓取量做大，而是让抓取节奏长期稳定在服务器可承受的区间里。
先把现有频次量清楚
调优之前，先看日志。不要凭感觉判断“蜘蛛是不是来太多”，用几个具体指标说话：
- 每分钟请求数：统计全天分布，重点看峰值时段，而不是平均值。峰值才决定服务器会不会扛不住。
- 来源分布：区分不同 UA、不同 IP 段的请求，确认是真实蜘蛛、镜像采集还是普通流量混在一起。
- 状态码结构：200、301、404、429、5xx 各占多少。5xx 和 429 的比例上升，通常说明资源已经吃到上限。
- 响应时间：按小时看 P95 而不是平均耗时，平均值会把问题抹平。
- 抓取目标集中度：是均匀落在所有入口页上，还是几十个页面吃掉了大半请求。
这些数据连续看一到两周，比任何经验判断都可靠。
服务器上的三个真实瓶颈
带宽与并发连接
入口页如果体积偏大、图片和外链资源多，单次抓取的流量成本会被放大。带宽打满时，最先出问题的不是新来的请求，而是已有连接的响应时间，表现为整体变慢。
应用进程与数据库
动态生成的入口页每次请求都要走一次程序和查询。进程池被占满后，请求会排队等待，日志里就会出现大量耗时很长的请求。入口页做成静态文件或由缓存直接返回，是最直接的一层减负。
同 IP 上的站点数量
同一个 IP 上堆了几十个入口页站点时，每个站点的抓取量即便都不高，加总起来也可能超过单机的处理能力。这种情况下拆分 IP 或拆分机器，往往比调限速参数更有效。
限速的手段与使用边界
- robots.txt 的 Crawl-delay：只有部分爬虫会读取，能起到一定分流作用，但不能当作唯一手段。设置过于激进的值，可能让正常抓取也变慢。
- 429 与 503：在确实过载时临时返回，并带上 Retry-After，属于“明确拒绝”的信号。适合短时间应急，不适合长期常态，否则入口页会被判定为不稳定。
- 缓存与静态化：CDN 或本地缓存命中后，抓取请求根本不落到源站。这是性价比最高的一层，优先做。
- 错峰与分批：新入口页分批次上线，每次只增加一部分，观察一周再继续，避免一次性把请求量抬高。
几个容易踩的误区
- 把日志里的请求数当成考核指标，为了数字好看而放松控制，结果源站频繁超时。
- 用多层跳转或 JS 跳转去“消耗”蜘蛛，实际上只是增加了入口页的失败率，还可能让链接被忽略。
- 长期返回 429，把限速当成日常状态，入口页的抓取频率反而会被压低。
- 只看平均值不看峰值，白天数据正常，凌晨集中抓取时服务器已经接近崩溃。
一个可执行的调整节奏
- 用两周日志建立基线：峰值请求数、峰值带宽、P95 响应时间。
- 按峰值留出三到五成余量，把目标并发定在这个水位以下。
- 先做缓存与静态化，再看是否还需要靠限速手段兜底。
- 每次只增加一批入口页，增量后回看状态码结构与响应时间，异常就停止加量。
- 把观察周期固定下来，每月复核一次，站点数量变化后重新评估。
抓取频次不是越高越好。入口页能稳定响应，才有被持续抓取的基础；频繁超时或返回异常状态，反而会让整个池子的可用性下降。