蜘蛛對站点的印象，不只是“頁面返回了什么”，還包括“拿回来的過程顺不顺”。同样的 HTML，放在毫秒級响應的静態文件上，和放在要等两秒的接口後面，蜘蛛後續的訪問节奏往往不一样。
蜘蛛能感知的几項服務器指标
從爬虫角度看，一次抓取大致會拆成：建立连接、發送請求、等待首字节（TTFB）、传輸正文、断開或复用连接。其中和服務器關系最直接的是 TTFB 與传輸速度，其次是错誤率。
- TTFB 偏高：常见于資料库慢查询、未命中缓存、服務端渲染較重、同步調用第三方接口。
- 传輸慢：正文体积大、未做压缩、带宽被占满、CDN 回源慢。
- 错誤率：5xx、超时、连接重置，哪怕只占几個百分点，也會影响判断。
响應變慢後，抓取节奏常见的變化
- 單位時間内的抓取請求數下降，两次訪問之間的間隔被拉長。
- 原本會逐层跟進的路径，可能停在某一层不再深入。
- 部分 URL 被反复尝试却拿不到完整响應，實际上等于没抓到。
- 如果站点同时在提交 Sitemap，新 URL 的首次發現也會被推後。
這些變化谈不上是惩罚，更像是爬虫在控制對單個主机的压力：拿不到就先登出，過一阵再来。問题在于，站点如果一直慢，這個“過一阵”會越来越長。
偶發 5xx 比稳定 503 更麻烦
整站维護时返回 503 並带上 Retry-After，蜘蛛通常能理解。真正容易出問题的是另一類：绝大多數請求是 200，但每隔几十次冒出一個 500 或網關超时。這種随机性让爬虫無法判断是临时故障還是頁面本身有問题，處理方式往往是降低频率、减少並發，把一個本来正常的站点当成不稳定站点對待。
排查时不妨把日誌按狀態碼和响應時間分组，看 5xx 是集中在某個接口、某台後端，還是集中在某個時間段。集中就說明是局部問题，不必大動干戈。
连接层也值得看一眼
除了應用层，连接复用、TLS 握手、DNS 解析、CDN 回源都在這一趟里。如果服務器對每個請求都重新握手，或者中途直接掐断 keep-alive，爬虫每次抓取的成本都會變高。表現出来就是：日誌里請求條目不少，但完成的有效抓取不多。
可以自查的几個信号
- 日誌里响應時間的中位數和 P95 差多少，長尾是否集中在某類 URL 上。
- 超时和 5xx 的占比，以及是否随着並發升高而明顯上升。
- 同一台服務器上多個站点的抓取量是否此消彼長，說明资源在互相挤占。
- Sitemap 中提交的 URL，從提交到首次出現抓取记錄的間隔有没有變長。
調整方向
- 把能静態化的頁面静態化，减少動態渲染带来的等待。
- 给爬虫路径單獨設定缓存與超时上限，避免慢接口拖住整條鏈路。
- 精简影响首屏的同步請求，正文尽早輸出，邊生成邊传輸。
- 错誤頁要稳定可辨：该 404 的別返回 200，该 503 的別返回 500，別让爬虫去猜。
- 扩容或限流不要一步到位，观察几天日誌里的抓取量變化再决定下一步。
服務器侧的稳定與响應速度，不直接决定頁面能不能被收錄，但它决定了蜘蛛愿不愿意多来几趟、多走几层。把抓取過程里的等待、超时和随机错誤压下去，後面谈内鏈结构和抓取路径優化才有意义。