為什么狀態碼正常，抓取量還是會掉
排查抓取問题时，很多人只盯狀態碼：200 就認為没問题，5xx 才去查服務器。但蜘蛛在拿到狀態碼之前，還要先完成 DNS 解析、建立 TCP 连接、完成 TLS 握手。這几步任何一环抖動，日誌里可能什么都不顯示，站長的感受却是「蜘蛛来得少了」。把抓取稳定性当成一條完整鏈路来看，比單看某一层更容易找到原因。
DNS：最先被忽略的一环
DNS 解析是所有抓取的起点。蜘蛛需要先解析域名，才能發起连接。常见問题包括：
- 權威 DNS 响應慢或不稳定：解析超时後，這次請求就結束了，不會留下任何 HTTP 狀態碼。
- 解析结果不一致：多地节点返回不同 IP，其中某個 IP 不可用，抓取就會时好时坏。
- TTL 設定過短：频繁回源解析，放大了 DNS 层的抖動。
- CNAME 鏈條過長：多級跳轉让解析時間成倍增加，使用多個第三方服務时尤其明顯。
建议固定几個時間点，用不同地区的解析工具测一下解析耗时和返回结果，確認没有明顯差异。
TLS 握手與證书的细节
HTTPS 站点在解析之後還要完成 TLS 握手。證书過期、證书鏈不完整、不支持蜘蛛常用的 TLS 版本、SNI 配置缺失，都會让连接直接失敗。這類失敗通常不會出現在服務器訪問日誌里，排查时容易漏掉。
可以做几件事：確認證书鏈完整（中間證书別缺），检查到期時間並設定提醒，確認 HTTP 與 HTTPS 都能正常返回内容，跳轉层級尽量控制在两級以内。跳轉本身不是問题，但连續多次跳轉叠加握手開销，會明顯拖慢每次抓取。
连接复用與 HTTP/2 的影响
同一批抓取里，蜘蛛往往希望复用连接，减少重复握手。如果 keep-alive 時間設定得過短、單 IP 並發连接數限制得很嚴，或者 HTTP/2 配置異常，每次請求都要重新建连，單位時間能抓到的 URL 數量就會下降。表現出来像是「抓取频次變低」，實际原因却在连接层。
响應阶段：慢和坏要分開處理
连接建立之後才轮到响應，這里有两個不同的信号：
- 慢：首字节時間（TTFB）偏長，蜘蛛需要等待。偶尔慢通常問题不大，持續慢會让它降低對這個目錄的訪問频率。
- 坏：5xx、连接重置、超时中断。這類信号更明确，蜘蛛一般會记錄失敗，隔一段時間再试；如果连續失敗，可能减少该目錄的抓取量。
需要注意的是，慢頁面和错誤頁面在日誌里的呈現方式不同：慢通常表現為請求耗时長，坏則表現為狀態碼或连接中断。分開統計，才能判断是该加缓存還是该查程序。
一份简單的稳定性巡检清單
- 多地区測試 DNS 解析耗时，確認返回结果一致。
- 检查證书鏈是否完整、是否临近到期。
- 確認 HTTP 與 HTTPS 都能正常响應，跳轉层級尽量少于两級。
- 查看訪問日誌中請求耗时的分布，找出慢 URL 集中出現的目錄。
- 統計 5xx 與连接中断的比例，確認是否集中在某台机器或某個接口。
- 對比服務器日誌與抓取工具里的抓取量變化，看波動是否與發布、压测、扩容的時間点吻合。
限流與故障要区別對待
429 和 503 有时是主動限流的信号，有时是真實過载。如果站点确實扛不住，用 robots.txt 的 crawl-delay 或服務端限流策略，比让蜘蛛不断撞上错誤更稳妥。反過来，如果只是個別机器配置問题，優先修机器，而不是一刀切地限制全站。
抓取稳定性是一條從上到下的鏈路：解析、握手、连接、响應。哪一层出問题，表現都可能是「蜘蛛變少了」，但處理方式完全不同。先把鏈路分段观测，再决定改哪里。