蜘蛛要抓到一個 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 更有效。