蜘蛛来訪的流程並不复杂：解析 DNS、建立连接、發出請求、等服務器返回第一個字节。前面几步通常在毫秒級完成，真正决定成败的是最後一步——服務器多久開始吐資料。如果這一步经常拖到几秒甚至超时，抓取就會中断，没抓到的地址下次是否還来，就不好说了。
先分清两個概念：响應時間與超时
响應時間常用的观察指标是 TTFB（首字节時間），它包含網絡往返、服務器排队、程序處理、資料库查询等环节。超时則是客戶端等不到结果就断開，蜘蛛通常有自己的等待上限，超過就记為失敗並換下一個地址。
這两個指标经常互相掩盖：TTFB 平均看着還行，但少數頁面要等十几秒，這些頁面在日誌里表現為超时或 5xx，數量不多，却集中在重要栏目上，影响就不小。所以看平均值之外，更要看慢請求的分布。
慢在哪：几種常见的响應拖沓来源
- 資料库慢查询：列表頁、标簽頁在資料量大时没有走索引，一次查询掃全表。
- 模板里嵌套調用：一個頁面里循环查多次資料库，或者調用多個内部接口。
- 外部接口同步等待：第三方接口變慢或挂掉，頁面就跟着卡住。
- 缓存没有覆盖到：首頁有缓存，栏目頁和内頁没有，蜘蛛偏偏抓的是後者。
- 後端连接數或進程數不足：並發一上来就排队，正常用戶也跟着變慢。
- 大文件與附件直出：视频、压缩包和頁面放在同一台机器上，带宽被占满。
把 5xx 和限流分清楚
服務器返回的错誤碼，蜘蛛的解讀並不相同：
- 500 類：服務端出错了，属于異常，反复出現會影响對這個站点的判断。
- 503：暂时不可用，通常配合 Retry-After 說明多久之後再来，适合計划内维護。
- 429：請求太频繁，是限流信号，语义上比 5xx 温和，但也要控制触發频率。
- 200 加错誤文案：最容易被忽略的一種，頁面上寫着"系統繁忙"，狀態碼却是 200，蜘蛛會当成正常内容收下。
维護期間，宁可返回明确的 503 加說明，也不要用 200 去糊一個错誤頁面。同时，限流尽量不要把蜘蛛和正常用戶一起挡掉，可以對已驗證的蜘蛛做适度放行，但這要结合自身日誌来判断，別把放行開關交给請求头里随便寫的名稱。
给不同類型的内容做响應分层
- 静態頁面和資料接口分開部署，至少不要争抢同一份连接资源。
- 對列表頁、聚合頁做结果缓存，缓存時間按更新频率设定，不必强求實时。
- 给耗时接口加超时上限和降級方案，接口超时就返回缺省内容，而不是让整個頁面挂住。
- 把大文件迁到對象存储或獨立域名，减轻主站带宽压力。
- 记錄慢請求日誌，把超過阈值的地址單獨列出来，定期看一次。
一份可以照着做的巡检清單
- 用命令行工具抓几條典型地址，记錄 TTFB、總耗时和狀態碼。
- 在蜘蛛日誌里筛出超时和 5xx，按目錄归並，看是否集中在某几個栏目。
- 检查資料库慢查询记錄，確認列表頁、搜尋頁是否存在全表掃描。
- 核對缓存命中率，重点看栏目頁和内頁。
- 確認维護頁面返回的是 503 而不是 200。
- 观察带宽峰值时段，看是否與蜘蛛抓取高峰重合。
响應速度是抓取的基础條件，不是加分項。站点内容再好，如果服務器经常让蜘蛛等太久，後面的工作都會打折。
把响應時間、错誤碼和限流策略整理成一份可复查的记錄，比偶尔手動测一次更有意义。長期看，稳定的响應表現會让抓取更顺畅，也让日常运维少一些临时的电话。