蜘蛛抓一個頁面，看起来只是一次 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 變更记錄和定期的多地连通性检查，能避免很多“查了半天頁面，問题却在地下”的情况。