看日志时经常会出现这样的画面：某一分钟里，来自同一搜索蜘蛛的请求突然密集起来，几十条挤在一起。这不是蜘蛛出了问题，而是它在按自己的并发策略抓取站点。了解并发从哪来、受什么影响，比单纯统计被抓了多少次更有意义。
蜘蛛不是一次只发一个请求
搜索引擎的抓取系统是分布式的，同一时间可能有多个抓取节点在访问你的站，每个节点内部还会维持一定数量的并行请求。你在日志里看到的并发数，通常是这些节点叠加后的结果。它受几个因素影响：
- 服务器响应时间：响应越快，同样的时间窗口内蜘蛛越敢提升并发。
- 历史抓取质量：错误率高、超时多的站点，蜘蛛会主动收缩并发。
- 页面重要程度：首页、热门栏目的抓取频次通常高于深层页面。
- 站点规模与更新频率：更新越频繁、结构越清晰的站，调度越积极。
换句话说，并发不是蜘蛛单方面决定的，它会根据站点给出的反馈不断调整。
响应时间会反过来限制抓取速率
很多人把抓取速率理解成搜索引擎的一项固定设置，实际上它和服务器响应时间互相拉扯。假设蜘蛛计划在某个时间段内抓一千个页面，如果单次响应从 200 毫秒变成 2 秒，它能完成的量会明显下降；同时，持续的慢响应会被当成压力信号，蜘蛛倾向于降低并发，避免把站点拖垮。
想让蜘蛛抓得更多，通常不是让它加快，而是让每个请求处理得更快。
这也是为什么提升抓取效率的常见做法是优化数据库查询、加缓存、减少重定向，而不是期待某天蜘蛛突然加大力度。
站点侧可以做的事
- 优先压缩响应时间，尤其是列表页、详情页这类被抓得最多的模板。
- 需要限流时，用 429 或 503 配合 Retry-After 做温和降速，比直接掐断连接更可控。
- 检查 CDN 和 WAF 的默认规则，确认没有把合法蜘蛛当成攻击流量拦截。
- 静态资源和图片交给 CDN，把源站的处理能力留给 HTML 请求。
直接封 IP 通常是最差的选择。蜘蛛被拒后不会立刻消失，反而可能在恢复访问后重新试探，而且不同搜索引擎的出口 IP 段会变化，维护封禁名单的成本很高。限流的目标是让蜘蛛慢下来，而不是让它放弃。
日志里怎么看出并发是否异常
把日志按秒或按分钟分组，统计来自同一蜘蛛的请求条数，就能大致还原并发曲线。需要一起看的还有：
- 响应时间是否在同一时段上升，如果并发一高响应就变慢，说明源站已经吃力。
- 是否出现 5xx，尤其是 502、504，这类错误往往会直接导致蜘蛛降速。
- 被抓的 URL 是否集中在少数模板上，过度集中通常意味着参数页或列表页被反复访问。
观察几天后一般能看出一个相对稳定的区间：正常时段并发在某条线以下，某次改版或某次活动后才明显抬高。这个区间比绝对值更有参考价值。
几个常见误区
- 把并发等同于攻击：真实的搜索蜘蛛并发通常和响应时间成反比，突发持续时间较短，和攻击流量的形态并不一样。
- 靠 robots.txt 限速：robots.txt 并不控制访问频率，Crawl-delay 的支持情况也不一致，指望它解决压力问题基本没用。
- 只看总量不看分布：一天抓十万次，如果九万次都落在同一个参数页上，说明抓取分配出了问题，而不是量不够。
并发是抓取系统的自然表现，站点能做的是把响应做稳、把结构做清晰，剩下的交给蜘蛛自己调节。