讨论抓取问题的时候，很多人直接从页面内容、内链和 Sitemap 开始看，但蜘蛛真正做的第一件事是建立连接。连接这一步失败，后面的 URL 发现、抓取排队、内容解析都无从谈起。这类问题在日志里往往不留下明显的状态码，只表现为抓取量突然下降，或者某些 URL 一直没被抓。下面按连接建立的顺序，把常见的几类故障点梳理一遍。
DNS：蜘蛛拿到 IP 之前
蜘蛛要先解析域名，才能发起连接。如果权威 DNS 不稳定、解析超时或返回 SERVFAIL，抓取请求在第一步就结束了。常见情况包括：
- 解析记录被误删，或指向了已经下线的 IP；
- 同一域名返回多个 IP，其中部分节点不可用，抓取请求恰好命中故障节点；
- TTL 设置过短导致解析结果频繁变化，或过长导致切换后迟迟不生效；
- 泛解析把不存在的子域也指向同一台服务器，产生大量可连接但无内容的地址。
排查时可以从多个地理位置做解析对比，确认返回的 IP 集合是否一致、是否都能连通。
TLS 证书：握手失败等于抓取失败
现在绝大多数抓取走的是 HTTPS。证书过期、证书链不完整、域名与证书不匹配、只支持过旧的协议套件，都会让握手直接失败。有些环境对证书链的完整性比较宽容，浏览器能自动补全中间证书，但抓取端不一定具备这个能力，于是浏览器打开一切正常，抓取却拿不到任何内容。
另一个容易被忽略的点是 SNI。同一 IP 上承载多个站点时，如果服务端不按 SNI 返回对应证书，抓取端可能拿到不属于该域名的证书，握手随之失败。证书续期、更换 CDN 证书之后，建议从外部节点做一次完整握手测试，而不是只在源站本地验证。
端口、协议与 IP 版本
标准情况下，蜘蛛访问的是 80 和 443 端口，并优先使用 HTTPS。如果站点只在非标准端口提供服务，或者把 HTTP 请求强制跳转到抓取端无法连接的地址，就会出现能发现、抓不到的情况。
IPv6 也值得留意。如果域名同时发布了 A 和 AAAA 记录，但 IPv6 链路实际不通，部分抓取请求会优先走 IPv6 并超时，重试后才回落到 IPv4，整体抓取节奏被拖慢。如果站点的 IPv6 支持还不完善，宁可先不发布 AAAA 记录。
超时、复位与被动限速
连接建立得慢，同样会消耗抓取机会。TCP 握手慢、TLS 握手慢、首字节迟迟不返回，都会让抓取端判断该地址暂时不可用，从而降低访问频率。除了服务器负载，中间的防火墙、DDoS 防护设备、云厂商的清洗策略也可能主动复位连接，表现为抓取请求被重置，而普通浏览器访问正常。
如果确认是安全设备误伤，比较稳妥的做法是在设备侧放行已知的抓取来源，而不是靠 User-Agent 做宽松白名单，因为 UA 本身是可以伪造的。
robots.txt 拉不到时会怎样
robots.txt 是抓取前必须读取的文件。如果它返回 5xx 或连接失败，抓取端通常会把这视为临时故障，暂时降低甚至暂停对该站点的抓取，等恢复后再继续；如果返回 404，一般会按没有限制处理，站点可以正常被抓。因此，robots.txt 所在的主机不能随意下线或做长时间维护，也要确保它本身没有被 CDN 缓存成错误结果，或跳转到需要登录的页面。
一个可用的排查顺序
- 用外部工具或第三方节点做 DNS 解析，确认返回的 IP 集合和本地一致，且每个 IP 都能连通；
- 对每个 IP 做一次完整的 HTTPS 握手，检查证书有效期、证书链和域名匹配；
- 确认 80 与 443 端口的可达性，检查是否存在强制跳转、端口变更，或 AAAA 记录指向不可用链路；
- 观察连接耗时，重点看 TCP 与 TLS 握手时间，而不是只看页面渲染时间；
- 检查防火墙、WAF、限速策略是否对抓取来源做了拦截；
- 最后确认 robots.txt 能稳定返回，且内容没有被缓存篡改。
连接层的问题往往不体现在页面本身，而是体现在抓取量和抓取频率这些整体指标上。与其在内容层面反复调整，不如先把这一层盯住：DNS 稳定、证书有效、端口可达、robots.txt 随时能读，抓取才有持续进行的基础。