讨论抓取問题时，多數人只盯着源站的訪問日誌。但今天大部分站点前面都有一层或多层缓存：CDN 邊缘节点、反向代理、頁面缓存插件、對象存储。蜘蛛發出的請求，很多时候根本没有到達你查看日誌的那台服務器，它拿到的是某一层缓存里的副本。理解這一点，才能解释一些看起来很矛盾的現象，比如“頁面明明已经改過，蜘蛛抓到的還是舊内容”。
一次請求可能穿過几层缓存
從蜘蛛到你的源站，路径大致是這样：
- 蜘蛛發起請求，先做 DNS 解析，通常解析到离它較近的 CDN 节点。
- 邊缘节点查自己的缓存，命中就直接返回，不會回源。
- 未命中时，向上一級缓存或父节点請求。
- 仍然未命中，才回到源站，源站生成頁面並逐层寫回缓存。
也就是说，蜘蛛的一次抓取可能完全没有碰到你的應用服務器。你看到的“零訪問”不等于蜘蛛没来；你看到的“頁面已更新”也不等于蜘蛛拿到的是新版。
缓存键决定了蜘蛛會拿到哪一份
缓存系統靠缓存键判断某個請求能不能复用一份已有的副本。缓存键通常包含域名、路径、查询字符串，有时還包含請求头。
Vary 與 User-Agent 分變体
如果配置里寫了按 User-Agent 区分缓存，例如给移動端返回另一套模板，蜘蛛的 UA 就可能對應一個單獨的變体。這個變体什么时候生成、什么时候過期，往往和普通用戶的副本不同步。结果是普通用戶看到新版，蜘蛛還在讀舊版。
缓存過期時間與發布节奏
缓存 TTL 设得長，好處是回源压力小、响應快；代價是内容更新後，蜘蛛可能在一段時間内拿不到新版本。頁面類 URL 的 TTL 一般不宜太長，尤其是詳情頁、列表頁這類经常變動的地址；静態资源則相反，可以设得很長，靠文件名或版本号来換新。
命中缓存和未命中，對蜘蛛意味着什么
- 命中缓存：响應通常在几十毫秒内返回，蜘蛛的抓取节奏顺畅，單位時間内能走更多 URL。
- 未命中回源：如果源站生成一個頁面要一两秒，蜘蛛就要等一两秒；同时回源請求會打到源站，遇到發布或批量更新时容易形成叠加。
- 错誤頁被缓存：這是最麻烦的一種。源站偶發 5xx 或超时，如果错誤响應被缓存层保留下来，蜘蛛會在 TTL 内反复拿到同样的错誤，抓取進度相当于被按下暫停键。
判断抓取異常时，先分清問题出在缓存层還是源站，再决定改配置還是改代碼。
怎么確認蜘蛛看到的是哪一版
不用猜，用几個手段交叉驗證：
- 看 CDN 或代理的訪問日誌，按蜘蛛 UA 過滤，观察狀態碼、缓存命中狀態與响應時間。多數 CDN 會标注 HIT 或 MISS。
- 對比源站日誌與 CDN 日誌的請求量差异，估算有多少抓取被缓存层拦下、没有回源。
- 從不同網絡位置請求同一個 URL，看返回内容是否一致；如果不同节点内容不同，說明缓存键或過期策略存在分歧。
- 检查响應头里的缓存相關字段，確認 TTL 與预期一致。
- 發布新内容後，观察蜘蛛下一次抓取拿到的版本，而不是只看自己浏览器里的结果。
几個容易踩的坑
- 只清源站缓存：改了内容却只重啟應用，CDN 上的舊副本仍在。
- 缓存了带參數的頁面：站内搜尋、排序、篩選參數组合被缓存，等于给大量低價值 URL 也做了副本，既占缓存空間也消耗抓取预算。
- 错誤响應進缓存：短暂故障被放大成持續故障，建议让 5xx 不缓存，或只缓存极短時間。
- 發布时批量失效：一次性把大量 URL 的缓存清掉，接下来蜘蛛集中回源，源站压力陡增，反而更容易出错。
小结
蜘蛛的抓取体驗，是它從 DNS 到拿到内容整條鏈路的综合结果。缓存层既是加速器，也是信息差所在。把缓存键、TTL、错誤响應策略這三件事理清楚，再回头看抓取日誌，很多“蜘蛛不抓”“抓的是舊版”的疑問會自己消解。