蜘蛛要抓到一个 URL，并不是“发出请求、收到页面”这么简单。从发现 URL 到真正拿到内容，中间会经过 DNS 解析、连接建立、TLS 握手、请求发送、首字节等待、内容传输和解析等多个环节。任何一个环节变慢或失败，都可能表现为“抓取少了”或“新 URL 迟迟不进来”。把链路拆开看，比只盯日志里的状态码更容易定位问题。
先分清“发现”和“抓取”
URL 发现发生在抓取之前。内链、Sitemap、RSS、接口输出等入口负责把 URL 放进待抓队列。发现之后，蜘蛛还要按调度策略决定什么时候访问。服务器稳定性、响应速度、错误率会影响调度器对站点的判断。因此，看到日志里 URL 变少时，先确认是发现入口出了问题，还是抓取链路被拖慢。
DNS 与连接建立阶段
第一个容易忽略的环节是 DNS 解析。如果解析超时、返回异常 IP，或者不同地区解析结果差异很大，蜘蛛可能还没发出 HTTP 请求就失败了。接着是 TCP 连接建立，防火墙、安全组、WAF 的限速策略都可能在这里拦截。
- 核对 DNS 解析时间是否稳定，是否存在解析轮询异常。
- 检查源站是否对陌生 IP 或高频 IP 做了连接限制。
- 观察连接复用是否正常，避免每次请求都重新握手。
TLS 握手与首字节等待
HTTPS 站点还要额外关注 TLS 握手。证书链不完整、协议版本过旧、加密套件不兼容，都可能让部分抓取客户端直接放弃。握手完成后，服务器处理请求并返回第一个字节，这段时间叫首字节时间。首字节时间过长，常见原因是数据库慢查询、页面同步调用外部接口、缓存未命中或源站负载过高。
如果日志里大量出现超时，但服务器负载看起来正常，可以按地区、按 UA、按 URL 类型分组观察。有时只是某类动态页面拖慢了整体响应，并非全站故障。
内容返回与解析阶段
内容开始返回后，还要看传输是否被中断。响应体过大、压缩配置异常、连接提前关闭，都会让蜘蛛拿到不完整页面。若页面依赖 JavaScript 渲染，首次返回的 HTML 里可能只有空壳，链接提取会延后到二次渲染队列。此时内链结构是否清晰、关键链接是否出现在初始 HTML 中，会直接影响后续 URL 的发现效率。
抓取链路核对的目标不是追求单次请求最快，而是让发现、调度、返回三个阶段都尽量可预测。
内链与 Sitemap 在链路中的位置
内链和 Sitemap 属于发现层。内链决定蜘蛛能否顺着路径走到深页，Sitemap 则提供补充入口。两者不互相替代：内链反映站点结构，Sitemap 适合声明更新频繁或入口较深的 URL。如果服务器在抓取时频繁超时，再完整的 Sitemap 也可能被延后处理。因此，发现入口的核对要和服务器响应核对放在一起看。
- 先看首页和栏目页是否稳定返回，确认主路径可用。
- 再检查深页内链是否被正确输出，避免链接依赖交互才出现。
- 最后核对 Sitemap 是否可访问、格式是否正确、更新时间是否合理。
记录与排查建议
排查时不要只看一个指标。可以同时记录 DNS 耗时、连接耗时、TLS 耗时、首字节时间和总耗时。对比不同时段、不同 URL 类型，找出波动最大的那一段。若问题集中在连接或 TLS 阶段，优先查网络和证书；若集中在首字节，优先查应用性能和缓存；若集中在内容传输，优先查响应体大小和压缩配置。
蜘蛛池或站群场景下，多个站点共用服务器、IP 或域名时，更要注意资源竞争。单个站点响应变慢，可能只是同一台机器上其他站点占用了连接数或带宽。把服务器稳定性、URL 发现入口和内链结构分开核对，再合起来看，通常比反复提交 Sitemap 更有效。