很多站点在日誌里看到同一秒钟出現十几條来自搜尋蜘蛛的請求，第一反應是“蜘蛛是不是在攻击我”。多數情况下，這只是正常抓取並發，和蜘蛛總量、抓取预算不是一回事。理解並發，才能判断服務器要不要加资源、要不要限流，以及限流之後抓取路径會不會變窄。
並發抓取指的是同一時間的连接數
蜘蛛抓取一個頁面，從建立连接到拿到响應，中間有一段時間。如果它同时打開多個连接去取不同 URL，站在服務器视角就是“並發”。同一個蜘蛛可能来自多個 IP 段，不同蜘蛛之間也會叠加，所以並發數往往大于你看到的單個 UA 計數。
並發高本身不代表異常。真正需要判断的是：這些請求是否挤占了正常用戶的资源。如果用戶訪問開始變慢、資料库连接池吃紧、P95 响應時間明顯上升，那才說明承载邊界被压到了。
哪些操作會把並發推高
- 一次性發布大量新 URL，Sitemap 也整批更新，蜘蛛可能集中来取。
- 列表頁、分頁、篩選參數生成出大量可抓取連結，内鏈把請求分散到许多 URL。
- 頁面响應變慢，蜘蛛為了维持抓取效率，可能增加连接或延長等待。
- CDN 回源配置不合理，邊缘节点各自回源，源站看到的並發被放大。
- 站内搜尋、日歷、對比頁等動態入口被大量抓取。
先看指标，再决定動作
建议至少观察這几項：按秒或按分钟聚合的蜘蛛請求數、並發连接數、响應時間 P95、错誤率、源站带宽和 CPU。把搜尋蜘蛛的請求單獨打标，和真實用戶流量分開看，否則限流容易誤伤。
可以给自己定一條简單的线：正常用戶高峰期，蜘蛛並發不超過源站能承受连接數的一定比例，留出余量。這個比例没有通用值，取决于你的架构和缓存命中率。
並發過高时的處理顺序
- 先優化响應：能静態化的頁面静態化，能缓存的加缓存，减少每次抓取都打資料库。
- 再考虑限流：在反向代理或 WAF 层针對蜘蛛 UA 做速率限制，注意保留正常抓取。
- 用狀態碼表達狀態：临时過载可以返回 503，並在响應头里给出 Retry-After，让蜘蛛稍後再来。
- 別長期返回空内容：如果一直用 200 却给空白頁，蜘蛛容易把它当成正常结果，後續判断會更乱。
robots.txt 里的 Crawl-delay 只有部分蜘蛛支持，不要把它当成唯一手段。更稳的做法是服務器端能接住，再配合 Sitemap 分批提交。
把發布节奏也当作並發控制
Sitemap 和内鏈是蜘蛛發現 URL 的入口，也是並發放大器。新站或大改版时，可以按栏目分批上线、分批更新 Sitemap，避免几千個 URL 在同一小时全部暴露。内鏈也可以分批加，先让核心頁面被稳定抓取，再逐步铺開長尾。
日誌里的並發怎么看
- 按秒統計蜘蛛請求條數，找出峰值出現的时段和對應 URL。
- 看峰值是否集中在少數几個模板或參數頁，如果是，優先治理這些入口。
- 對比限流前後的抓取量、响應時間和错誤率，確認没有把正常抓取挡掉。
留一條回归路径
並發策略不是设一次就結束。上新、改版、大促、CDN 調整之後，都值得重新看一遍日誌。把蜘蛛抓取当成一種需要容量的正常流量来規划，服務器稳定，抓取路径才不容易断。
並發不是要压到零，而是让蜘蛛和真實用戶都能在可接受的响應時間里拿到頁面。