很多人看抓取問题，习惯從 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 發現之後的流程少一些無谓的损耗。