讨论抓取問题时，注意力往往集中在 HTML 上：内鏈怎么寫、Sitemap 有没有提交、頁面能不能渲染。但從蜘蛛發起請求到它真正讀到第一段 HTML，中間還隔着 DNS 解析、连接建立、TLS 握手、服務器處理這几步。任何一步出問题，蜘蛛拿到的都不是内容，而是一條失敗记錄，而你在頁面上做的所有優化都還没来得及參與。
DNS 解析：抓取鏈路的最前排
請求要落到服務器，第一步是把域名解析成 IP。這一步出問题，服務器日誌上通常什么都不會留下——請求压根没到。
- 解析超时或間歇失敗：權威 DNS 不稳定、單点解析服務波動，都會让一部分蜘蛛請求直接失敗，且往往表現為偶發、不規律。
- CNAME 层數過多：CDN、邮件、驗證服務层层嵌套，解析鏈越長，中間环节越多，超时概率越高。
- TTL 設定過短：频繁變更解析结果會让缓存失效，蜘蛛每次解析都要重新走一遍全流程。
- 多地解析结果不一致：不同地区的蜘蛛拿到不同 IP，如果其中一個 IP 長時間不可用，問题只在部分区域出現。
排查时可以先對比本地與外部解析工具的结果，確認解析是否稳定、返回的 IP 是否都在正常服務。
TCP 连接與 TLS 握手
解析成功之後是建立连接。這一步的問题通常有迹可循，因為它會体現在响應時間上。
- 證书鏈不完整：部分客戶端能连、部分连不上，是典型的中間證书缺失表現。
- 證书過期或域名不匹配：直接用證书自检工具看有效期和覆盖的域名，比凭印象可靠。
- 协议與加密套件過舊或過新：只支持老舊版本，或者只保留少數新套件，都可能让一部分抓取端握手失敗。
- 未開啟會话复用：蜘蛛批量抓取时會反复握手，每次完整握手都會增加整体耗时。
首字节時間：後端到底花了多久
TLS 握手完成後，服務器開始處理請求，直到返回第一個字节，這段時間就是 TTFB。它是抓取体驗里最容易被忽视、又最直接影响抓取节奏的一环。
常见原因包括：動態頁面每次都要查库、缓存命中率低、後端與資料库跨机房通信、慢查询堆积。表現是响應時間忽高忽低，蜘蛛在高峰期拿不到稳定响應。做法不复杂：能静態化的静態化，能缓存的加缓存，把不常變的内容從請求鏈路里挪出去。
CDN 與回源：別让节点成為新的瓶颈
用了 CDN 之後，蜘蛛訪問的是节点，节点再回源。問题也常出在這一段：
- 回源地址配置错誤或回源 IP 變更後未同步，节点返回 5xx。
- 缓存規則把搜尋蜘蛛直接穿透到源站，源站扛不住批量請求。
- 不同地区节点质量差异大，同一 URL 在不同区域表現完全不同。
如果發現抓取異常集中在某些区域，優先查节点與回源，而不是先改頁面。
一條可用的排查顺序
- 確認請求是否到達服務器：日誌里没有记錄，先查 DNS 與 CDN 层。
- 看响應時間分布：握手慢還是後端慢，两者的處理方向完全不同。
- 检查證书有效期與證书鏈完整性。
- 對比不同地区、不同時間段的抓取表現，判断是全局問题還是局部問题。
- 把源站的直接訪問與经過 CDN 的訪問分別测一遍，定位瓶颈在哪一层。
抓取是一條鏈，鏈條前端的任何一环断了，後面做得再细致也传不到蜘蛛那里。與其反复調整頁面细节，不如先把 DNS、證书、响應時間這些基础項確認一遍。
這些检查不需要多复杂的工具，很多問题在常規的解析查询、證书檢測和响應時間监测里就能看出来。把入口這一步做稳，後面關于内鏈、Sitemap 和抓取路径的優化才有意义。