Scrapy限速算法到底在測什么？

你的爬蟲明明開了自動限速，為什么還是被拉黑？問題可能出在：它根本不看HTTP狀態碼。

AutoThrottle是Scrapy最實用的生產級功能之一，也是配置錯誤率最高的。多數教程讓你復制四行設置就完事，但沒人解釋算法實際在算什么、假設了什么、這些假設何時失效。這篇文章拆解它的底層邏輯，以及真實場景下的調參策略。

核心機制：測延遲，不看碼

AutoThrottle的調整依據只有一個指標——響應延遲（response latency），即從發出請求到收到響應的時間。它從不檢查你是否收到429、503或其他任何暗示限流的狀態碼。

響應快，算法判定服務器有容量，縮短請求間隔；響應慢，判定負載高，延長間隔。目標是維持一個預設的并發請求數，通過調節延遲讓實際并發逼近目標值。

這套邏輯的前提是：服務器延遲能準確反映負載。但這個前提在三種常見場景下會崩。

場景一：CDN緩存陷阱

邊緣節點返回緩存內容時，延遲可能低于1毫秒。AutoThrottle看到極快響應，會激進縮短延遲，瘋狂轟炸源站——而算法從未直接觀測過源站狀態。

你以為是智能限速，實際在給源站制造突發流量。

場景二：靜默限流

部分網站返回200狀態碼，但內容是軟攔截頁、驗證碼、反爬挑戰或空結果，且響應依然很快。AutoThrottle將其解讀為"服務器健康"，維持高速請求。

你已經被封了，算法還在踩油門。

場景三：策略型限流

服務器用毫秒級速度返回429，AutoThrottle同樣視為"快速健康響應"。當限流是硬性策略而非負載反應時，基于延遲的調節完全失效。

五個參數，三個關鍵

控制AutoThrottle行為的設置共五項，日常調參只需關注其中三個：

AUTOTHROTTLE_ENABLED = True —— 總開關

AUTOTHROTTLE_START_DELAY = 1.0 —— 算法接管前的初始延遲，用于前幾個請求

AUTOTHROTTLE_MAX_DELAY = 60.0 —— 計算延遲的上限，防止極慢服務器導致無限退避

AUTOTHROTTLE_TARGET_CONCURRENCY = 1.0 —— 目標并發請求數，這是調節的核心靶點

AUTOTHROTTLE_DEBUG = False —— 是否記錄每次限速決策，調參階段建議開啟

理解算法在測什么，才能決定何時用它。在動手調延遲之前，先搞清楚自己的請求需求特征——《The recipe for a request: Scaling data extraction》一文主張，選定爬取策略前務必仔細調研這些需求。