很多站点在流量不大时并不会注意抓取速率，直到某天日志里出现大量 5xx，或者监控显示 CPU 在某个时段被拉满，才回头去找原因。蜘蛛的访问是有节奏的，但这个节奏会随着它对站点的判断而变化。理解这层关系，比单纯盯着“今天来了多少次”更有用。
抓取速率由谁决定
蜘蛛的抓取频率并不是站点单方面能设定的。它通常参考几个因素：站点的历史响应速度、可用性、页面更新频率，以及站点规模。响应越稳定、越快的站点，往往会被允许更高的并发；而经常超时、经常返回 5xx 的站点，抓取速率会被自动压低。
这意味着服务器性能和抓取量之间是一个循环：性能好，抓得多；抓得多，如果扛不住，性能变差，抓取量又降下去。要跳出这个循环，关键是把响应时间控制在一个稳定的区间，而不是偶尔很快、偶尔卡死。
服务器端最先出现的三个信号
- 响应时间被拉长：平时两百毫秒的页面变成两秒，蜘蛛的连接会占用更久，等于变相降低了它单位时间内能抓的页面数。
- 5xx 变多：尤其是 503 和超时，蜘蛛会把这理解成“现在不适合来”，随后降低频率。
- 连接被中断：部分抓取在建立连接阶段就被拒绝，日志里表现为不完整的请求记录。
这三个信号不一定同时出现。有时只是响应时间变慢，抓取量就已经在慢慢下滑，但因为不报错，很容易被忽略。
限速信号应该怎么给
如果确实需要控制蜘蛛的访问强度，用正确的方式表达比直接封 IP 更合适。常见做法是返回 503 或 429，并附带 Retry-After 头，告诉对方多久之后再试。这样做的好处是，蜘蛛知道这是临时状态，不会把 URL 当作失效处理。
直接返回 403 或干脆断开连接，容易被理解成永久拒绝，可能影响后续的回访节奏。
crawl-delay 的位置
robots.txt 里的 crawl-delay 只被部分抓取方参考，而且它是一个全局值，无法细分到不同目录。对大站来说，逐个模板设限速并不现实，更实际的思路是从服务器侧做区分：把静态资源、列表页、详情页放到不同的处理能力上，避免某类 URL 拖垮整站。
把压力从高峰挪开的几种做法
- 给动态查询类 URL 加缓存，减少每次抓取都回源查询数据库。
- 把分页、筛选、排序等高组合参数页做合并或收敛，减少可抓 URL 总量。
- 用 CDN 或反向代理承接静态请求，让源站只处理必要的动态部分。
- 在流量高峰前预留资源，别让抓取高峰和业务高峰撞在同一时段。
- 对确实不需要被抓的路径，用 robots.txt 明确说明，减少无意义的请求。
日常自查可以看什么
- 按 UA 过滤日志，统计蜘蛛的响应时间分布，而不只是请求次数。
- 关注 5xx 的占比和出现时段，判断是持续问题还是尖峰问题。
- 看单次抓取的平均耗时是否在变长，这是最早期的一个信号。
- 对比改版、上新、活动前后的抓取量变化，找出关联。
抓取速率本质上是一种“信任额度”，站点越稳定，额度越容易维持。与其研究怎么让蜘蛛多来，不如先把响应时间和错误率压住，剩下的往往会自然发生。