讨论抓取問题的时候，很多人直接從頁面内容、内鏈和 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 随时能讀，抓取才有持續進行的基础。