把蜘蛛池的入口頁放到 CDN 後面，通常能改善訪問速度、分摊带宽，但也常带来一個新問题：真人訪問正常，蜘蛛却频繁拿到 403、503，或者只拿到一頁需要执行 JavaScript 的驗證頁面。多數情况下，原因不在蜘蛛池本身，而在 CDN 的缓存策略、回源規則和防護配置。下面按“先判断、再調整”的顺序，把常见的坑和检查方法说清楚。
先確認蜘蛛實际拿到了什么
不要只看浏览器里的效果。用命令行模拟蜘蛛請求，對比直连源站與走 CDN 的返回结果，差异点通常就是問题所在。
- 指定 UA 請求：带上主流蜘蛛的 User-Agent 發請求，看狀態碼、响應头與正文前几百字节。
- 對比源站直连：同一個 URL 直连源站 IP，如果源站正常、CDN 異常，問题就在邊缘层。
- 看 CDN 日誌：統計狀態碼分布與缓存命中比例，確認 403、429、503 集中在哪些路径。
- 检查正文：返回 200 但正文是驗證頁、跳轉脚本或空壳，對蜘蛛来说等同于抓取失敗。
三類最容易誤伤蜘蛛的配置
1. 浏览器完整性检查與 JS 挑战
這類功能依赖执行 JavaScript 或儲存 cookie 才能通過，而蜘蛛一般不执行脚本、不带 cookie。開啟後，入口頁在蜘蛛眼里就成了無法通過的關卡。以静態内容為主的入口頁，建议直接關閉针對蜘蛛 UA 的挑战策略。
2. UA 频控與 IP 限速
蜘蛛抓取往往短時間集中請求，容易被邊缘节点判定為異常流量，触發限速或临时封禁。合理的做法是按已驗證的蜘蛛来源單獨放行或放宽阈值，而不是一刀切。僅凭 UA 放行並不可靠，最好结合反向解析或官方公布的 IP 段做校驗，减少伪蜘蛛混入。
3. 缓存策略把错誤頁面缓存住
有些配置會把 404、5xx 或重定向一起缓存，而且缓存時間不短。结果是源站已经修好，邊缘节点還在持續给蜘蛛返回舊结果。5xx 和 4xx 通常應設定較短缓存或干脆不缓存；缓存键也要避免把不同 UA 的结果混進同一個缓存池，導致真人拿到蜘蛛版本或反之。
回源日誌與真實来源的识別
接入 CDN 後，源站日誌里记錄的訪問 IP 會變成邊缘节点 IP，直接用来源 IP 判断蜘蛛就會失真。需要在回源請求中保留原始客戶端 IP（例如通過 X-Forwarded-For 這類通用头部），再结合 UA 與反向解析来判断。同时保留一份 CDN 侧日誌，两邊對照，才能確認蜘蛛是否真的到達源站。
缓存 TTL 與内容更新节奏
- 入口頁作為發現 URL 的枢纽，更新频率不高，静態部分可以给較長的 TTL，减少回源压力。
- 列表頁、會新增連結的頁面，TTL 不宜過長，否則新 URL 迟迟不出現在蜘蛛视野里。
- 不要對同一份内容同时設定互相矛盾的 Cache-Control 與 CDN 面板規則，邊缘通常按更嚴格的一方执行。
- 如果入口頁會按 UA 或来源返回不同模板，明确哪些版本允许缓存，避免蜘蛛拿到给其他场景准备的頁面。
一份可落地的检查清單
- 用蜘蛛 UA 直连源站與走 CDN 各請求一次，记錄狀態碼與正文特征。
- 關閉或放宽针對蜘蛛的 JS 挑战、驗證碼與频控規則。
- 確認 4xx、5xx 不會被長時間缓存。
- 让回源請求保留原始客戶端 IP，日誌可追溯。
- 静態资源與 HTML 的缓存規則分開設定，两者不必相同。
- 調整後隔几天再看一次日誌，確認異常狀態碼下降，而不是只看單次請求。
CDN 預設面向“防御”和“节省带宽”，而蜘蛛需要的是稳定、可预期的响應。把這两套規則分開配置，通常就够用了。
最後提醒一点：CDN 节点 IP 會調整，DNS 记錄的 TTL 也影响蜘蛛多久切換地址。換节点或換回源方案後，留出解析生效的時間，別在当天就下结论。