不少蜘蛛池在搭建初期跑得挺顺，接入 CDN 之後反而出現抓取量下滑、入口頁像是被冻住的情况。問题往往不在池子本身，而在加速层：爬虫拿到的可能不是你刚更新的那份頁面，甚至可能是一個被缓存下来的错誤狀態。把這一层理清楚，比繼續加域名更有效。
缓存會把入口頁冻在某個版本
CDN 的預設逻辑是尽量少回源。入口頁如果被当成静態资源缓存住，就會出現這样的场景：你改了标题、換了内鏈、調整了跳轉目标，源站已经生效，邊缘节点還在返回几天前的舊副本。
對普通訪客来说影响不大，對爬虫来说却是另一回事——它每次到訪看到的都一样，自然没有理由提高回訪频率。入口頁的價值恰恰在于看起来還在维護，一旦被缓存冻住，這個信号就传不出去。
- 入口頁的缓存 TTL 建议压短，几百秒以内比較稳妥；
- 需要频繁調整的入口頁，可以按路径單獨設定規則；
- 内容完全静態、長期不動的入口頁才适合長缓存。
多节点副本不一致，會让抓取信号變乱
CDN 有很多邊缘节点，不同节点的回源時間不同，缓存副本自然不同。同一個 URL，爬虫從不同节点抓到的内容可能有差异，返回的响應头、ETag、Last-Modified 也可能對不上。
單次差异通常不致命，但如果入口頁本身就依赖動態參數、随机推荐位或者時間戳，版本碎片會更多。對比之下，一個稳定、统一、變化可控的頁面，更容易让爬虫把它当成值得定期回来看看的地址。
做法不复杂：入口頁尽量减少随机元素，改動之後主動刷新缓存，別等 TTL 自然過期。
最怕的是错誤狀態被缓存
源站短暂抖動，入口頁返回了一次 503；或者某條規則誤伤，返回了一次 404。如果這類响應被邊缘节点缓存住，後續爬虫拿到的一直是同一個错誤。
入口頁的 4xx、5xx 响應不應该被缓存，或者只能缓存极短時間。一次誤缓存，可能让一個入口頁在很長一段時間里對爬虫完全失去意义。
配置上通常把错誤狀態碼排除在缓存之外，同时给源站加一個简單的健康检查，避免把抖動放大成持續故障。
CDN 的安全策略也會挡住真爬虫
不少 CDN 預設開着人机校驗、UA 黑名單、频率限制。正常的搜尋爬虫有时會被誤判，尤其是来自陌生 IP 段、没有 Referer、請求头不完整的訪問。表現出来的現象是：訪客能打開入口頁，爬虫却经常拿不到完整内容，甚至直接被拒绝。
比較稳妥的處理方式是把已知爬虫的 UA 特征加入白名單，或者對入口頁路径放宽校驗，把防護重点放在後台、接口這些真正敏感的位置。限流阈值也要留出余量，別让爬虫的並發刚好卡在触發线上。
回源日誌才是能用的抓取记錄
只盯 CDN 的訪問日誌，很容易誤判：日誌里记錄的是邊缘节点 IP，不是訪客 IP，缓存命中的請求甚至根本不會出現在回源日誌里。想看清爬虫行為，需要两邊的資料配合。
- 回源日誌里保留 UA、X-Forwarded-For、缓存命中狀態；
- 区分命中缓存的抓取和回源的抓取，两者反映的問题不一样；
- 長期观察同一入口頁的回源次數變化，比看總訪問量更有參考價值。
一份可以直接抄的配置清單
- 入口頁缓存 TTL 控制在几分钟内，改動後主動刷新；
- 4xx、5xx 狀態一律不缓存；
- 已知搜尋爬虫 UA 走白名單，减少安全策略誤伤；
- 保留回源日誌，字段包含 UA 與 XFF；
- 目标頁可以适当缓存，入口頁谨慎使用長缓存；
- CDN 不要一關了之，源站被打挂同样會導致抓取失敗。
说到底，CDN 不是蜘蛛池的對立面。它承担的是带宽和抗压，蜘蛛池承担的是被發現的机會。把缓存規則、错誤狀態和安全策略這三件事理清楚，入口頁對爬虫来说才是稳定可讀的；反之，池子铺得再多，爬虫每次来都看到同一份舊副本或者一個被缓存下来的 404，效果也不會好到哪里去。