入口站是蜘蛛進入蜘蛛池的第一道门。很多人搭好入口頁之後會顺手给域名套一层 CDN，理由通常是加速、防打、隐藏源站。但對蜘蛛池来说，CDN 改變的不只是速度，它還會影响蜘蛛解析到的 IP、拿到的响應头，以及它到底抓的是源站還是缓存副本。這几点没想清楚，入口頁在蜘蛛那邊可能和你在浏览器里看到的完全是两回事。
一、CDN 之後，蜘蛛解析到的 IP 不再是你的源站 IP
最简單的判断方式：本地 dig 一下入口域名，如果返回的是一组 CDN 厂商的地址，那蜘蛛做 DNS 解析时拿到的也是這一组，而不是你服務器的真實 IP。這本身不是坏事，但會带来两個连鎖反應。
- 你之前在日誌里看到的蜘蛛来訪记錄，會先落在 CDN 节点上。源站日誌里能不能看到蜘蛛，取决于 CDN 是否回源、回源时是否透传真實 UA 與客戶端 IP。
- 如果 CDN 開啟了某些安全策略，把不带浏览器特征的請求挡在邊缘，蜘蛛可能连源站都没碰到就被拦下，日誌里干干净净，你會誤判成“蜘蛛不来”。
所以上 CDN 之後第一件事，是確認邊缘节点對搜尋引擎 UA 是放行的，並且回源請求带着可识別的标识，否則後面所有關于抓取节奏的判断都會失真。
二、缓存副本：蜘蛛抓到的可能不是目前版本
入口頁如果被 CDN 缓存，蜘蛛拿到的是缓存节点上的副本。對内容長期不動的入口頁，這没什么問题；但對那種频繁調整連結、替換目标站的入口頁，就會出現“你自己看已经改了，蜘蛛抓到的還是老版本”的情况。
常见的表現是：你在後台更新了入口頁的連結指向，几天後蜘蛛行為没有變化，因為它抓的還是缓存里的舊 HTML。要避免這種情况，入口頁這類需要及时生效的頁面，缓存時間要么设得很短，要么在更新後主動刷新缓存。
三、回源比例與抓取效率
CDN 的命中率越高，回源越少，源站压力越小。但蜘蛛抓取和普通用戶訪問不太一样：它可能集中在某個时段大量請求同一批 URL。如果缓存命中率低，這些請求會一起打到源站，反而比不套 CDN 时更集中。
另一個容易被忽略的点是响應头。源站直连时，你返回的狀態碼、缓存控制、内容類型都比較直观；经過 CDN 之後，部分头信息可能被改寫或补充。如果入口頁依赖某些响應头做判断，建议上 CDN 前後各抓一次完整响應，對比一遍。
四、哪些情况适合给入口站上 CDN
- 入口站數量多、分布在多個域名上，源站带宽有限，需要把流量摊到邊缘。
- 入口頁内容相對稳定，缓存時間可以设得較長，命中率高。
- 源站 IP 不想暴露，或者需要一定的抗压能力。
五、哪些情况不建议上
- 入口頁需要频繁調整連結和指向，缓存刷新不及时會拖慢生效速度。
- 你需要靠源站日誌精确分析蜘蛛来訪时段和抓取路径，而 CDN 日誌不完整或没有回源明细。
- CDN 預設策略比較激進，容易誤伤非浏览器特征的請求。
六、上线前後可以自己做的几項检查
- 解析對比：分別用本地和第三方工具解析入口域名，记錄返回的 IP 段。
- 响應头對比：上 CDN 前後各抓一次响應头，重点看狀態碼、缓存控制和内容類型是否被改動。
- UA 放行測試：模拟搜尋引擎 UA 請求入口頁，確認返回的是正常頁面而不是驗證頁或拦截頁。
- 缓存驗證：更新入口頁内容後，观察抓到的版本多久發生變化。
- 日誌核對：確認源站或 CDN 日誌里能看到带真實 UA 的来訪记錄。
CDN 本身只是鏈路中的一环，它不决定蜘蛛来不来，但會改變蜘蛛看到什么。判断标准很简單：你在浏览器里看到的入口頁，和蜘蛛抓到的入口頁，是不是同一份東西。
如果你的入口站規模不大、日誌分析需求又比較强，直连源站反而更省事；如果入口站數量多、需要分摊压力，那就在上线 CDN 之前把 UA 放行、缓存策略和日誌透传這三件事確認好，再去看蜘蛛的行為資料，结论才靠得住。