很多站点在流量不大时並不會注意抓取速率，直到某天日誌里出現大量 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 的占比和出現时段，判断是持續問题還是尖峰問题。
- 看單次抓取的平均耗时是否在變長，這是最早期的一個信号。
- 對比改版、上新、活動前後的抓取量變化，找出關联。
抓取速率本质上是一種“信任額度”，站点越稳定，額度越容易维持。與其研究怎么让蜘蛛多来，不如先把响應時間和错誤率压住，剩下的往往會自然發生。