给蜘蛛池的入口頁挂 CDN，是個看着划算、實际需要先想清楚的選擇。CDN 能扛住流量、降低源站压力，但它同时插在爬虫和源站之間，既改變了爬虫看到的响應，也改變了你看到的日誌。下面按几個實际會碰到的环节拆開说。
CDN 在這里到底改變了什么
入口頁的任務是把爬虫引到目标頁，它對响應速度的要求不算高，但對两件事要求比較高：每次訪問都能拿到正确的内容，以及事後能看清谁来過。CDN 恰好在這两点上都動了手——内容可能来自缓存而不是源站，訪問记錄可能落在 CDN 侧而不是你的服務器日誌里。
缓存：爬虫拿到的可能不是你刚改的那版
入口頁如果内容更新不频繁，缓存确實能减少回源、加快响應。問题出在缓存策略和更新节奏不匹配的时候：
- 缓存時間设得很長，改了锚文本或連結指向，爬虫在缓存過期前仍然看到舊版。
- 缓存時間设得很短，CDN 基本形同虚设，回源压力並没减轻。
- 按 URL 缓存但忽略查询參數差异，不同參數的入口頁被当成同一個頁面返回。
比較稳妥的做法是给入口頁單獨设一條缓存規則，不要和图片、静態资源混在一起；調整過連結结构的那批頁面，改完之後主動刷新一次缓存，而不是等它自然過期。
回源與日誌：谁真正抓了你的頁面
爬虫訪問 CDN 节点，节点再回源，這會带来两個後果：源站日誌里大量记錄是 CDN 节点的 IP，而不是爬虫的 IP；如果請求命中缓存直接返回，源站甚至不會产生這條记錄。
怎么把真實来源留下来
要判断抓取情况，得看 CDN 侧的訪問日誌，或者让 CDN 在回源請求里带上原始訪問者 IP 的請求头，源站再按這個头去记錄。否則很容易出現“日誌里一片节点 IP，看不出蜘蛛有没有来過”的情况，後面做频次統計、分层分析就没法落地。
多节点差异：同一份内容，不同地方返回不一样
CDN 多节点部署，正常情况下内容應当一致，但下面几種情况會让结果产生偏差：
- 部分节点缓存未同步，某些地区返回的還是舊版本。
- 节点侧做了地区限制或跳轉，一部分来源的請求被拦截或導向別處。
- HTTPS 證书在部分节点未配置或已過期，訪問直接失敗。
這些問题的共同点是：你在本地測試时看不出異常，抓取方從別的網絡位置訪問时却是另一種结果。定期從几個不同地区做一次响應比對，比只在本地刷新頁面有用得多。
常见的几個配置坑
- CDN 侧的安全策略拦掉爬虫。人机校驗、频率限制、地区封鎖如果配在 CDN 上，源站里设的白名單就失去意义了。
- 回源协议和證书不匹配。CDN 用 HTTPS 回源、源站只有 HTTP，或者反過来，都會導致回源失敗。
- 把缓存当成稳定保證。缓存是為了提速，不是為了固定内容；入口頁的稳定靠的是源站内容本身不频繁變動。
- 日誌只留一處。只留源站日誌會漏掉命中缓存的訪問，只留 CDN 日誌則可能因為保留期偏短而丢資料。
什么情况下值得上，什么情况下不必
入口頁數量多、單机压力大，或者确實有多個地区需要响應时，CDN 是有意义的。如果入口頁總量不大、源站本身就够用，那 CDN 只是多了一层需要维護的环节，還要額外處理真實 IP 和缓存刷新，算下来未必划算。
判断标准可以简單一点：你上 CDN 是為了解决一個具体的承载或响應問题，還是只是觉得“大家都上”。前者值得配，後者可以先不上。