讨论抓取问题时，注意力往往集中在 HTML 上：内链怎么写、Sitemap 有没有提交、页面能不能渲染。但从蜘蛛发起请求到它真正读到第一段 HTML，中间还隔着 DNS 解析、连接建立、TLS 握手、服务器处理这几步。任何一步出问题，蜘蛛拿到的都不是内容，而是一条失败记录，而你在页面上做的所有优化都还没来得及参与。
DNS 解析：抓取链路的最前排
请求要落到服务器，第一步是把域名解析成 IP。这一步出问题，服务器日志上通常什么都不会留下——请求压根没到。
- 解析超时或间歇失败：权威 DNS 不稳定、单点解析服务波动，都会让一部分蜘蛛请求直接失败，且往往表现为偶发、不规律。
- CNAME 层数过多：CDN、邮件、验证服务层层嵌套，解析链越长，中间环节越多，超时概率越高。
- TTL 设置过短：频繁变更解析结果会让缓存失效，蜘蛛每次解析都要重新走一遍全流程。
- 多地解析结果不一致：不同地区的蜘蛛拿到不同 IP，如果其中一个 IP 长时间不可用，问题只在部分区域出现。
排查时可以先对比本地与外部解析工具的结果，确认解析是否稳定、返回的 IP 是否都在正常服务。
TCP 连接与 TLS 握手
解析成功之后是建立连接。这一步的问题通常有迹可循，因为它会体现在响应时间上。
- 证书链不完整：部分客户端能连、部分连不上，是典型的中间证书缺失表现。
- 证书过期或域名不匹配：直接用证书自检工具看有效期和覆盖的域名，比凭印象可靠。
- 协议与加密套件过旧或过新：只支持老旧版本，或者只保留少数新套件，都可能让一部分抓取端握手失败。
- 未开启会话复用：蜘蛛批量抓取时会反复握手，每次完整握手都会增加整体耗时。
首字节时间：后端到底花了多久
TLS 握手完成后，服务器开始处理请求，直到返回第一个字节，这段时间就是 TTFB。它是抓取体验里最容易被忽视、又最直接影响抓取节奏的一环。
常见原因包括：动态页面每次都要查库、缓存命中率低、后端与数据库跨机房通信、慢查询堆积。表现是响应时间忽高忽低，蜘蛛在高峰期拿不到稳定响应。做法不复杂：能静态化的静态化，能缓存的加缓存，把不常变的内容从请求链路里挪出去。
CDN 与回源：别让节点成为新的瓶颈
用了 CDN 之后，蜘蛛访问的是节点，节点再回源。问题也常出在这一段：
- 回源地址配置错误或回源 IP 变更后未同步，节点返回 5xx。
- 缓存规则把搜索蜘蛛直接穿透到源站，源站扛不住批量请求。
- 不同地区节点质量差异大，同一 URL 在不同区域表现完全不同。
如果发现抓取异常集中在某些区域，优先查节点与回源，而不是先改页面。
一条可用的排查顺序
- 确认请求是否到达服务器：日志里没有记录，先查 DNS 与 CDN 层。
- 看响应时间分布：握手慢还是后端慢，两者的处理方向完全不同。
- 检查证书有效期与证书链完整性。
- 对比不同地区、不同时间段的抓取表现，判断是全局问题还是局部问题。
- 把源站的直接访问与经过 CDN 的访问分别测一遍，定位瓶颈在哪一层。
抓取是一条链，链条前端的任何一环断了，后面做得再细致也传不到蜘蛛那里。与其反复调整页面细节，不如先把 DNS、证书、响应时间这些基础项确认一遍。
这些检查不需要多复杂的工具，很多问题在常规的解析查询、证书检测和响应时间监测里就能看出来。把入口这一步做稳，后面关于内链、Sitemap 和抓取路径的优化才有意义。