很多人看抓取问题，习惯从 HTTP 状态码和页面内容入手。但蜘蛛在拿到状态码之前，还要完成几步连接操作：把域名解析成 IP、和服务器建立 TCP 连接、完成 TLS 握手，然后才发出 HTTP 请求。这些前置环节如果变慢或失败，蜘蛛看到的不是 404 或 500，而是连接层面的错误。URL 明明写在 Sitemap 和内链里，也可能一直停在“已发现、未抓取”的状态。
DNS 解析：URL 发现的第一步
蜘蛛拿到一个 URL，第一步是解析域名。如果 DNS 解析超时、返回 SERVFAIL，或者解析结果在多个 IP 之间来回变化，抓取就会在发出请求之前中断。
常见情况有几类：
- 域名刚刚更换 DNS 服务商，全球生效还没完成，不同地区的解析结果不一致。
- 权威 DNS 响应慢，蜘蛛在超时时间内拿不到答案，直接放弃这次抓取。
- 同一个域名返回多个 IP，其中部分 IP 已经下线，蜘蛛随机命中后就连接失败。
- CNAME 链过长，解析过程多绕了几跳，增加了失败概率。
对站点运营来说，DNS 本身通常不是每天要看的东西，但在改版、迁移、换服务商之后，值得用多地解析工具确认一遍。内链和 Sitemap 里的 URL 不会因为 DNS 出问题而消失，蜘蛛下次仍可能再来，但如果解析长期不稳定，URL 从被发现到被请求之间就会一直卡着。
TLS 握手与证书：连接建立阶段的常见断点
现在绝大多数站点走 HTTPS。蜘蛛在 TCP 连接之后，需要完成 TLS 握手才能发请求。这一段出问题，表现往往不是页面报错，而是抓取工具直接记录连接失败。
容易踩到的点包括：
- 证书过期或链不完整。 浏览器可能给用户一个警告页，蜘蛛则可能直接终止抓取。
- 证书域名不匹配。 比如证书只签了带 www 的域名，但内链里混用了裸域，蜘蛛访问裸域时握手失败。
- SNI 配置缺失。 同一 IP 上托管多个站点时，服务器没有正确返回对应证书，蜘蛛可能拿到默认站点的证书。
- 协议版本不兼容。 服务器只支持较旧的 TLS 版本，或者只支持很新的版本，与蜘蛛客户端的支持范围对不上。
这些问题不需要每天检查，但在证书续期、CDN 切换、服务器迁移之后，最好用外部工具从多个地区验证一次。站内 URL 是否可发现，前提是这个域名能顺利完成握手。
连接超时与重试：蜘蛛会不会再回来
蜘蛛对连接阶段通常有超时设置。DNS 解析、TCP 连接、TLS 握手各自可能被限制在几秒内。超过之后，这次抓取就记为失败。蜘蛛一般会重试，但重试次数和间隔并不透明，也不会因为某个 URL 失败就无限等待。
如果服务器在特定时段负载很高，连接队列被占满，新连接需要排队甚至被丢弃，蜘蛛遇到的就会是超时。此时站点地图里的 URL 仍然有效，内链也没有问题，但抓取节奏会被拖慢。减少这种情况，可以从几方面入手：
- 确认服务器在蜘蛛来访时段是否有足够的连接处理能力。
- 检查防火墙或安全策略有没有对蜘蛛 IP 段做限速或拦截。
- 观察日志里连接重置、超时的比例，而不是只看 HTTP 状态码。
- 如果用了多台源站，确认负载均衡不会把蜘蛛请求打到已经下线的节点。
对 URL 发现的实际影响
连接阶段的问题有一个特点：它不区分 URL 的好坏。一个栏目页、一篇详情页、一张 Sitemap 里的地址，只要落在同一个故障域名或 IP 上，都会一起受影响。内链结构再清晰，也不能绕过 DNS 和握手。
因此，排查抓取问题时，可以把顺序倒过来：先确认域名能正常解析、证书有效、连接稳定，再看 robots.txt、状态码和页面内容。反过来做，容易在内容层找不到原因。
连接阶段稳定，是 URL 从“被发现”走到“被请求”的基础条件。它不保证内容被收录，但连接长期失败时，后面的优化很难生效。
最后提醒一点：蜘蛛的抓取行为由搜索引擎控制，站点能做的是让连接环节尽量少出错，而不是去承诺某个 URL 一定被抓取。把 DNS、TLS 和超时监控纳入日常巡检，至少能让 URL 发现之后的流程少一些无谓的损耗。