聊抓取时，大家习惯盯着“蜘蛛今天来了几次”“抓了多少個頁面”，却很少問一個更底层的問题：它同时開了几條连接。這件事直接决定了 URL 被發現的速度，也决定了服務器在某一秒钟要承受多大的压力。
抓取不是一條线在走
蜘蛛對同一個站点的抓取通常是並發的：同一時間可能有几個到十几個請求同时打進来，分散在不同的 URL 上。所以你在日誌里经常看到同一秒出現好几條记錄，時間戳互相重叠。並發數高，新連結被發現得快；並發數被压得很低，新 URL 就只能慢慢排队，Sitemap 里的條目也要等更久才轮到。
並發數由哪些因素决定
- 站点响應速度：响應越快，搜尋引擎越愿意提高並發；慢站点會被自動降速。
- 歷史抓取表現：長期稳定、错誤少的站点，抓取节奏更從容。
- 错誤率：5xx、超时、连接被重置，都會让並發被主動压低。
- 站点規模與更新频率：内容多、更新勤的站点，抓取需求更大。
- 服務器反馈：明确的限速信号會被參考，但不同引擎的遵循程度不一样。
從日誌里看並發
不需要复杂工具，把一天的訪問日誌按秒切分就能看出大概：
- 同一秒内属于同一来源 IP 的請求條數，近似等于当时的並發量。
- 响應時間的中位數和長尾值，長尾越長，並發越容易被拖下来。
- 5xx 與 429 的占比，比例升高往往意味着服務器在主動拒绝。
- 限速前後抓取條數的變化，能反推你對並發的干预是否過头。
连接复用比一次次新建更划算
如果每個請求都重新握手，蜘蛛和服務器都要付出額外開销：TCP 三次握手、TLS 协商、线程建立。開啟 Keep-Alive 或使用 HTTP/2 的多路复用後，同一條连接可以承载多個請求，抓取吞吐會更平稳。所以服務器上的连接空闲超时不要设得太短，否則蜘蛛刚建立好的连接很快被断開，它只能反复重连，你也會在日誌里看到大量短连接。
服務器端该怎么配合
- 保證稳定响應，避免請求長時間挂起不返回。
- 需要降速时，用 503 加 Retry-After 告诉對方稍後再来，而不是直接封 IP。
- 把图片、脚本等静態资源交给 CDN，把並發額度留给 HTML。
- 用 DNS 回查確認来源，別把真蜘蛛和假蜘蛛一起挡在门外。
- 盯着並發峰值與資料库连接數，避免首頁或列表頁被拖垮。
限速不會让蜘蛛消失，只會让 URL 發現變慢。如果你的站点每天都有新頁面需要被發現，過度限速就等于把它們按在队尾。
一份简單的自检清單
- 取一周日誌，統計每日同一秒的最大並發與平均值。
- 對比响應時間曲线與抓取條數曲线，看是否此消彼長。
- 確認 Sitemap 的获取間隔是否被明顯拉長。
- 抽查新發布頁面的首次被抓時間，是否比一個月前變慢。
- 检查是否有连接被服務端提前關閉的情况。
並發连接是個双向指标：它既是蜘蛛對站点的信任度，也是服務器能不能接得住的考驗。把响應做稳、把错誤率压下去、把降速方式換成温和的 503，抓取节奏自然會回到一個双方都舒服的位置。