蜘蛛抓一个页面，看起来只是一次 GET 请求。但在真正发出请求之前，它要先完成 DNS 解析、TCP 建连、TLS 握手这几步。这几步中任何一环出问题，蜘蛛都会在“还没看到你的页面”之前就放弃，日志里甚至连一条访问记录都不会留下。这也解释了为什么有些抓取问题在服务器访问日志里怎么查都查不到痕迹。
先搞清楚：这些环节为什么不在日志里
服务器访问日志记录的是“请求已经到达 Web 服务之后”的事情。而 DNS 解析失败、TCP 连接丢包、TLS 握手被拒绝，都发生在请求到达之前。所以当你发现某个栏目长期抓不到、日志里却没有任何对应记录时，问题往往在更下面一层，而不是页面内容本身。
DNS：最容易被忽略的一层
蜘蛛有自己的解析节点，通常分布在多个地区。可能出现的情况包括：
- 解析超时：权威 DNS 响应慢，蜘蛛在超时时间内拿不到 IP，直接跳过这次抓取。
- 多地解析结果不一致：部分节点拿到旧 IP 或错误 IP，导致这些节点的抓取持续失败，而其他节点一切正常。
- 记录冲突：同一主机名同时存在 CNAME 与 A 记录，或存在指向不存在主机的 CNAME，会让部分解析器直接判定失败。
自查时可以用多个地区的公共 DNS 分别解析一次，对比结果是否一致；同时关注权威 DNS 的 TTL，改版或迁移前把 TTL 提前调低，能减少切换期间的解析混乱。
TLS 证书：握手失败最常见的原因
证书到期最典型，但它往往不会让全站“立刻打不开”——浏览器可能因为用户手动放行而看起来正常，蜘蛛则会直接中断。除了到期，还要注意：
- 中间证书缺失，部分客户端无法补全证书链；
- 证书里的域名与实际访问域名不匹配，例如只签了带 www 的域名，没覆盖裸域或某些子域名；
- SNI 配置错误，多个站点共用同一 IP 时证书返回错乱；
- 只支持过旧的协议版本，或不支持主流的加密套件。
这类问题建议用独立的检测手段验证，而不是只用本机浏览器打开看看——本地可能因为缓存或系统信任链的差异而掩盖问题。
协议版本与连接复用
HTTP/2、HTTP/3 对蜘蛛通常是有利的：连接复用可以减少每次抓取的建连开销。但如果服务端配置不完整，比如协议协商失败后回退异常、或对某些客户端直接断开，反而可能出现“部分请求成功、部分请求被重置”的情况。表现为同一时间段抓取请求量骤降，或日志里出现大量不完整的连接记录。
IPv6、CDN 回源与限流
如果站点启用了 IPv6，建议确认 AAAA 记录指向的地址确实可用。曾经出现过的典型问题是：A 记录正常，AAAA 记录指向一台没有正确配置的机器，支持 IPv6 的抓取节点全部失败，只走 IPv4 的节点正常，于是就出现了“抓取量莫名减半”的现象。
使用 CDN 时，还要看回源环节。边缘节点正常返回，但回源超时或回源被源站限流，蜘蛛拿到的仍然是错误状态。同时注意不要让 WAF 的速率限制把正常抓取误判为攻击，阈值最好结合自己的抓取量留出余量。
一个可执行的排查顺序
- 确认域名在多地解析结果一致、权威 DNS 响应正常；
- 检查证书有效期、证书链完整性与域名覆盖范围；
- 确认 IPv4 与 IPv6 两条路径都能正常建连；
- 检查 CDN 回源与源站限流策略，排除误拦截；
- 最后再回到页面层，检查响应码、robots 规则与内容本身。
抓取问题不一定出在页面里。当日志安静得不正常时，先怀疑“蜘蛛根本没连上”，再怀疑“蜘蛛连上了但不喜欢”。
把握手环节当成抓取链路的第一段来维护，配合证书到期提醒、DNS 变更记录和定期的多地连通性检查，能避免很多“查了半天页面，问题却在地下”的情况。