看日誌时经常會出現這样的画面：某一分钟里，来自同一搜尋蜘蛛的請求突然密集起来，几十條挤在一起。這不是蜘蛛出了問题，而是它在按自己的並發策略抓取站点。了解並發從哪来、受什么影响，比單纯統計被抓了多少次更有意义。
蜘蛛不是一次只發一個請求
搜尋引擎的抓取系統是分布式的，同一時間可能有多個抓取节点在訪問你的站，每個节点内部還會维持一定數量的並行請求。你在日誌里看到的並發數，通常是這些节点叠加後的结果。它受几個因素影响：
- 服務器响應時間：响應越快，同样的時間窗口内蜘蛛越敢提升並發。
- 歷史抓取质量：错誤率高、超时多的站点，蜘蛛會主動收缩並發。
- 頁面重要程度：首頁、热门栏目的抓取频次通常高于深层頁面。
- 站点規模與更新频率：更新越频繁、结构越清晰的站，調度越积极。
換句话说，並發不是蜘蛛單方面决定的，它會根據站点给出的反馈不断調整。
响應時間會反過来限制抓取速率
很多人把抓取速率理解成搜尋引擎的一項固定設定，實际上它和服務器响應時間互相拉扯。假设蜘蛛計划在某個時間段内抓一千個頁面，如果單次响應從 200 毫秒變成 2 秒，它能完成的量會明顯下降；同时，持續的慢响應會被当成压力信号，蜘蛛倾向于降低並發，避免把站点拖垮。
想让蜘蛛抓得更多，通常不是让它加快，而是让每個請求處理得更快。
這也是為什么提升抓取效率的常见做法是優化資料库查询、加缓存、减少重定向，而不是期待某天蜘蛛突然加大力度。
站点侧可以做的事
- 優先压缩响應時間，尤其是列表頁、詳情頁這類被抓得最多的模板。
- 需要限流时，用 429 或 503 配合 Retry-After 做温和降速，比直接掐断连接更可控。
- 检查 CDN 和 WAF 的預設規則，確認没有把合法蜘蛛当成攻击流量拦截。
- 静態资源和图片交给 CDN，把源站的處理能力留给 HTML 請求。
直接封 IP 通常是最差的選擇。蜘蛛被拒後不會立刻消失，反而可能在恢复訪問後重新试探，而且不同搜尋引擎的出口 IP 段會變化，维護封禁名單的成本很高。限流的目标是让蜘蛛慢下来，而不是让它放弃。
日誌里怎么看出並發是否異常
把日誌按秒或按分钟分组，統計来自同一蜘蛛的請求條數，就能大致還原並發曲线。需要一起看的還有：
- 响應時間是否在同一时段上升，如果並發一高响應就變慢，說明源站已经吃力。
- 是否出現 5xx，尤其是 502、504，這類错誤往往會直接導致蜘蛛降速。
- 被抓的 URL 是否集中在少數模板上，過度集中通常意味着參數頁或列表頁被反复訪問。
观察几天後一般能看出一個相對稳定的区間：正常时段並發在某條线以下，某次改版或某次活動後才明顯抬高。這個区間比绝對值更有參考價值。
几個常见誤区
- 把並發等同于攻击：真實的搜尋蜘蛛並發通常和响應時間成反比，突發持續時間較短，和攻击流量的形態並不一样。
- 靠 robots.txt 限速：robots.txt 並不控制訪問频率，Crawl-delay 的支持情况也不一致，指望它解决压力問题基本没用。
- 只看總量不看分布：一天抓十萬次，如果九萬次都落在同一個參數頁上，說明抓取分配出了問题，而不是量不够。
並發是抓取系統的自然表現，站点能做的是把响應做稳、把结构做清晰，剩下的交给蜘蛛自己調节。