從 DNS 到首字节：蜘蛛請求一個 URL 时，哪一步最容易卡住

很多人排查抓取問题，习惯從内容层面入手：内鏈够不够、Sitemap 全不全、頁面有没有重复。但蜘蛛能不能拿到頁面，第一步其實發生在内容之前——它得先把請求發出去，並且完整地收到响應。這一段鏈路里任何一环出問题，反映到抓取統計上都是“抓取量下降”，可原因完全不同。

一次抓取要走的几步

把蜘蛛当成一個普通的 HTTP 客戶端，它訪問一個 URL 大致會经過這些环节：

其中前面几步是“不产生頁面内容”的纯開销。它們快，蜘蛛就能在同样的時間里多抓几個頁面；它們慢或者失敗，蜘蛛连内容都看不到。

DNS 是最容易被忽略的一环。它通常很快，但一旦出問题，影响面比服務器本身還大：

這類問题的特点是“时好时坏”，日誌里能看到一部分抓取成功、一部分直接连不上。

HTTPS 站点在拿到頁面之前還要過證书這一關。常见的坑包括：

這類問题往往表現為整站抓取骤降，而不是某几個頁面出問题。

服務器收到請求後多久吐出第一個字节，直接决定蜘蛛這一次抓取要占用多久的连接。首字节慢，常见原因有：

首字节之後，响應体要完整传完才算一次成功抓取。连接被中途重置、响應体被截断、返回的長度声明和實际内容對不上，都會让蜘蛛拿到半截頁面。半截頁面里的連結自然也是残缺的，這會直接影响後續的 URL 發現。

不需要額外工具，几份現成的資料就能大致定位：

抓取量下降时，先確認蜘蛛能不能正常拿到完整的响應，再去查内容和内鏈。顺序反了，容易在没問题的地方反复改。

归根结底，URL 發現和内容质量决定蜘蛛“愿意抓多少”，而這條從 DNS 到首字节的鏈路决定蜘蛛“能不能抓到”。两者都顺的时候，抓取量的變化才更接近内容层面的真實反馈。