蜘蛛愿意来，不等于抓得完。很多站点内容正常、Sitemap 也提交了，抓取量却長期低位徘徊，最後追到服務器這一层：响應慢、偶發超时、5xx 間歇报错。抓取队列有時間预算，一次請求超时，這一轮基本就放弃了，重试要等下一轮；同一批 URL 被超时反复打断，重新抓取間隔就會被拉長。所以抓取衰减常常不是“蜘蛛不来”，而是“来了没抓成”。
先把問题量化，再動手改
凭感觉調服務器參數，很容易改错方向。建议先同时看两類資料：蜘蛛侧和服務端侧。
抓取日誌里值得關注的字段
- 响應狀態分布：200、301/302、404、429、5xx 各自占比，尤其看 5xx 是否集中在某几個 URL 或某個时段。
- 响應耗时：按路径分组統計，找出明顯慢于站点平均值的模板頁，比如带篩選條件的列表頁、聚合頁。
- 重试痕迹：同一 URL 在短時間被多次請求而始终未成功，說明服務端在拖後腿而不是入口不足。
- 抓取时段分布：如果失敗請求集中在流量高峰，多半是资源争抢，而不是蜘蛛本身的問题。
服務端要看的指标
- TTFB（首字节時間）的 P95、P99，而不是只看平均值；平均值好看、長尾很慢是常见情况。
- 資料库慢查询數量、缓存命中率、PHP/應用進程排队情况。
- 带宽出口是否被打满，静態资源是否與頁面請求争抢连接。
- 反向代理與源站之間的超时設定是否短于應用實际處理時間。
常见诱因與處理方向
- 模板頁查询過重：列表頁每次動態拼装、缺少缓存，是最典型的 TTFB 高發点。给列表頁做短周期缓存，比優化單個頁面更有效。
- 缺少压缩：HTML 未啟用 gzip 或 brotli，传輸体积翻倍，在带宽紧張时直接表現為慢和超时。開啟压缩後注意 Content-Length 與實际長度一致，避免响應被截断。
- 连接與超时設定不匹配：代理层超时设得比應用短，請求會被提前掐断並返回 5xx。让上游超时留出余量，比事後加机器更省事。
- 第三方资源阻塞：頁面渲染依赖外部接口，接口抖動就拖慢整頁。關键内容尽量服務端直出。
- 抓取與用戶流量争抢：高並發时段可以让蜘蛛命中的缓存優先走静態层，减少對資料库的冲击。
429 與 503 不能同等對待
限流返回 429，通常表示服務器主動拒绝，抓取方會放缓节奏甚至降低频次；503 多表示临时的服務不可用，两者都會抑制抓取，但處理方式不同。如果确實需要限速，應尽量让限流只针對異常高频請求，而不是無差別拦截，否則正常的 URL 發現也會被一起压住。使用 Retry-After 提示恢复時間，比直接返回错誤更利于抓取調度。
調整後设一個观察窗口
改完不要当天就下结论。建议以两到四周為一個观察周期，對比調整前後的抓取日誌：成功請求數、5xx 占比、TTFB 的 P95，以及热门與長尾目錄的抓取覆盖變化。若成功數上升但覆盖率没動，說明瓶颈已從服務器轉到入口或内鏈结构，下一轮再處理那條线。
抓取衰减的排查顺序，建议從“看不到的服務端”走到“看得到的入口”：先確認响應是否稳定、是否能在合理時間内返回完整内容，再谈 Sitemap、内鏈與 URL 發現。服務器這一层没理顺，後面的入口優化很难体現出来。