站点管理人员常遇到这样的情况：日志里看不到蜘蛛的请求，或者请求来了却没抓走页面，于是第一反应是改 robots、改内链、加 Sitemap。但抓取一个 URL 本身是分段完成的，在蜘蛛读到 HTML 之前，它已经走了好几步。先把失败落在哪一层找出来，比盲目改站点更省事。
一次抓取要经过的几个阶段
1. 域名解析
蜘蛛先要把 URL 里的域名解析成 IP。这一步的常见问题包括：权威 DNS 响应慢、解析结果不稳定（不同节点拿到不同 IP）、CNAME 链路过长。表现往往是抓取时断时续，而不是彻底抓不到。如果站点用了多线路解析或智能 DNS，需要确认所有线路都能正常响应。
2. 建立连接与 TLS 握手
解析到 IP 之后要完成 TCP 连接，HTTPS 站点还要做 TLS 握手。证书过期、证书链不完整、只支持老旧的加密套件，都可能让握手直接失败。这类问题在浏览器里容易被缓存掩盖，而蜘蛛每次都是新连接，反而更容易撞上。
3. 发送请求，等待首字节
请求发出去之后，服务器什么时候返回第一个字节（TTFB）很关键。如果页面是动态生成的，数据库慢、接口阻塞、缓存未命中，都会把 TTFB 拉长。蜘蛛在连接上等待的时间是有限的，超时之后它拿不到任何内容，只会记一次失败。
4. 读取响应头
响应头决定蜘蛛接下来怎么处理这个地址：状态码是 200 还是 301、有没有 noindex、内容类型是不是 text/html。很多抓取异常并不是打不开，而是打开后被告知「不要这个版本」。
5. 读取正文
拿到正文才算真的抓完。正文被中途截断、压缩方式不支持、编码声明和实际编码不一致，都会让蜘蛛拿到残缺内容。页面体积过大时，也可能只取到前面一部分。
怎么判断卡在哪一层
- 服务器日志里连连接记录都没有：大概率在解析或网络可达性这一层。
- 有连接但没有完整的请求行：多半卡在握手阶段，或连接被中途关闭。
- 有请求行、长时间没有响应状态：重点看后端处理时间和超时设置。
- 有状态码但内容为空：检查响应头、压缩方式与输出逻辑。
几个容易被忽略的细节
- 多节点环境：负载均衡后面的机器配置不一致，就会出现「有时能抓、有时不能抓」。
- 错误页面本身也慢：如果 404、500 页面还要跑完整套框架，失败请求同样消耗资源。
- 拦截设备在中间：WAF 或防护策略可能让连接在握手后就被切断，日志里看起来像客户端主动断开。
- IPv6 与 IPv4：只配好一边，另一边解析出来却连不上，会造成间歇性失败。
抓取失败是一个结果，不是原因。把 DNS、连接、TLS、首字节、正文这几个阶段分开看，能很快缩小范围。
可以按顺序做的小检查
- 用蜘蛛的 UA 从外部节点实际请求一次，确认完整链路是否正常。
- 对比带缓存和不带缓存的响应时间，看慢在哪一段。
- 检查证书有效期与证书链，尤其是 CDN 回源的那一段。
- 确认错误页面和重定向不会拖慢服务器，也不要引发额外的重试风暴。
- 观察一段时间内的失败分布，是个别 IP、个别目录，还是全站范围。
把这些分层看清楚之后，再回头调整内链、Sitemap 或者抓取频次，思路会清晰很多。蜘蛛能不能稳定抓到内容，取决于整条链路，而不只是页面本身写得好不好。