為什么會想到给入口頁上 CDN
入口頁數量上去以後，最先暴露的往往是两個問题：一是带宽和並發，二是源站 IP 太集中。看到 CDN 宣传里寫着“缓存加速、隐藏源站、多节点”，很多人第一反應就是给入口頁套一层。但入口頁和普通内容站不太一样，它本身内容少、更新频繁、還要看蜘蛛訪問日誌，套上 CDN 之後有些東西會變得看不清。
CDN 能带来的三個真實收益
- 分摊並發压力：入口頁大多是静態 HTML，命中缓存後回源請求很少，几百個入口頁用一台小机器也能扛住。
- 源站 IP 不直接暴露：蜘蛛和掃描器看到的是 CDN 节点 IP，源站可以只放行 CDN 回源段。
- 解析和响應更稳：就近接入能在一定程度上压住 TTFB 波動，對跨地域訪問有一定帮助。
這三点的前提是：你确實在看訪問日誌、确實需要隐藏源站、确實有並發压力。如果一條都不沾，CDN 更多是增加一层排查成本。
代價一：日誌被切走一半
入口頁的價值很大一部分来自日誌——哪個蜘蛛来了、来了几次、抓的是哪個 URL。接入 CDN 後，請求先到节点，节点日誌和源站日誌對不上，命中缓存的請求根本不會回源，源站日誌里就是空白。要看全量，就得去 CDN 控制台導日誌，或者用回源日誌加节点日誌做拼接，工作量不小。
如果入口頁的主要用途是观察蜘蛛行為，缓存命中带来的日誌缺失會直接影响判断，這一点往往比带宽成本更值得優先考虑。
代價二：内容更新和缓存互相打架
入口頁常常需要改标题、換連結、調整跳轉目标。缓存 TTL 设得長，改動生效就慢；设得短，CDN 的意义又打折。更麻烦的是，某些节点已经缓存了舊版本，蜘蛛抓到的和你以為的不一样，排查时容易誤判成“入口頁失效”。
代價三：IP 分散可能只是错觉
不少 CDN 的节点 IP 段是公開且集中的，同一家 CDN 上的入口頁，出口 IP 段高度重合。指望靠 CDN 把入口頁 IP 打散，效果通常有限。真正需要 IP 分散时，獨立 IP、不同 C 段、不同机房，往往比套一层 CDN 更直接。
缓存策略怎么配
- 入口頁 HTML 建议短缓存或不缓存，例如 Cache-Control: no-cache，让节点每次回源校驗，兼顾速度和更新。
- 頁面里的 CSS、JS、图片可以長缓存，用文件名或版本參數区分。
- 需要按 UA 区分的入口頁，務必確認 CDN 的缓存键是否包含 UA，否則移動端和桌面端模板會互相串頁。
- 回源超时和重试次數按源站實际能力設定，別让 CDN 的重试把源站打满。
回源和真實 IP 怎么處理
源站要在日誌里拿到蜘蛛真實 IP，就需要 CDN 传递 X-Forwarded-For 或 X-Real-IP，並在 Web 服務器里配置信任的回源段；否則日誌里全是节点 IP，蜘蛛识別無從谈起。反過来，源站最好只放行 CDN 回源 IP 段，避免被绕過 CDN 直接打上来。
适合與不适合的场景
- 适合：入口頁規模大、以静態頁為主、並發压力明顯、需要隐藏源站。
- 不适合：入口頁只有几十個、主要靠日誌判断蜘蛛行為、内容一天改几次、运维精力有限。
一個折中做法
把入口頁分成两组：量大且不常改的走 CDN，量小或處于观察期的直连源站。這样既保留了一部分干净的日誌，又不至于让全部入口頁都暴露在同一個 IP 上。無论怎么選，入口頁只是让蜘蛛更容易發現 URL 的一环，它不承诺收錄，也不解决内容质量和排名問题，加不加 CDN 都不會改變這一点。