做抓取分析时，一個常见的誤区是把源站日誌当成蜘蛛来過與否的唯一證據。實际上，只要站点前面挂了 CDN 或反向代理，蜘蛛的大部分請求可能根本没有落到源站，而是被邊缘节点用缓存副本直接返回了。理解這一层，對判断抓取情况很關键。
蜘蛛的請求先落到哪一层
一次普通的 HTML 抓取，路径大致是：DNS 解析 → 邊缘节点 → 命中則直接返回、未命中則回源 → 源站生成响應 → 邊缘缓存並返回给蜘蛛。也就是说，源站日誌里缺失的那部分抓取，未必是蜘蛛没来，可能只是被缓存接住了。
這带来两個直接影响：一是你看到的抓取量會被低估，二是源站統計的响應時間並不等于蜘蛛實际等待的時間。分析抓取节奏时，最好把邊缘日誌和源站日誌放在一起看。
缓存命中率如何影响抓取节奏
邊缘命中的响應通常在几十毫秒内完成，蜘蛛拿到頁面後可以很快發起下一個請求。命中率低时，每個請求都要回源，源站要重新渲染、查询、拼装，單次抓取占用的连接時間被拉長，蜘蛛在同一時間窗口里能走完的 URL 自然减少。
- 命中率高：抓取更顺畅，單頁耗时短，蜘蛛更愿意往目錄深處走。
- 命中率低：回源压力集中，容易出現排队和超时，抓取速度被压下来。
- 缓存频繁失效（短 TTL 叠加大量不同參數）：效果接近没有缓存。
需要提醒的是，抓取量上升並不等于缓存配置就變好了，也可能只是内容更新的正常波動。做前後對比时尽量控制變量。
几種常见的“缓存挡路”情况
對搜尋引擎 UA 做了驗證挑战
部分 CDN 或安全产品的預設策略，會對疑似自動化的請求彈出 JS 挑战或驗證頁。如果搜尋引擎的 UA 没有進入白名單，蜘蛛拿到的就是一段挑战脚本，而不是頁面内容。
错誤頁被缓存
源站短暂故障返回 5xx，如果邊缘把 5xx 也缓存下来，蜘蛛和用戶都會在故障恢复後繼續拿到错誤頁。建议明确配置：5xx 不缓存，或只缓存极短時間。
Vary 头寫得過宽
Vary: Cookie、Vary: User-Agent 這類設定會让缓存按维度拆分成大量副本，命中率骤降。面向公開頁面的缓存，通常不需要按 Cookie 区分。
不同节点拿到不同版本
多节点、多线路回源时，可能出現 A 节点是舊版、B 节点是新版的情况。蜘蛛從不同 IP 抓取，看到的版本可能不一致，進而影响它對内容更新時間的判断。
内容更新與缓存 TTL 的错位
頁面更新後如果没有及时刷新缓存，蜘蛛抓到的仍是舊版本，它可能據此認為頁面没有變化，降低後續的回訪频率。更麻烦的是，如果這时 Last-Modified 或 ETag 與缓存副本對不上，304 的判断也會變得混乱。
發布關键頁面时顺手做一次主動刷新，比事後排查“為什么蜘蛛没看到新内容”要省事得多。
几條可以落地的检查動作
- 用同一台机器，分別带搜尋引擎 UA 與普通浏览器 UA 請求同一 URL，對比返回内容是否一致。
- 確認 CDN 的爬虫策略中，已知搜尋引擎 UA 處于放行狀態，没有被挑战或限速。
- 检查缓存規則，确保 5xx 與错誤頁不會長期驻留。
- 對比邊缘日誌與源站日誌中的抓取记錄，估算實际被缓存接住的抓取占比。
- 對更新频繁的栏目頁設定較短 TTL，或纳入主動刷新清單。
把缓存层纳入抓取分析的视野，很多“蜘蛛没来”“内容不更新”的疑問會更容易解释。它不改變蜘蛛的行為規則，但會改變你能看到什么。