为什么会想到给入口页上 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 都不会改变这一点。