CDN和源站怎样配合才能稳定加速？

很多网站接入 CDN 后，静态文件速度有所提升，但仍会出现首页偶尔变慢、更新后用户看到旧内容、源站被突发请求压垮等问题。根因通常不是节点数量不足，而是CDN与源站配合不完整：域名解析、缓存规则、回源协议和源站保护必须保持一致。

以使用 Cloudflare、Amazon CloudFront、Akamai 或云厂商 CDN 的网站为例，接入前先把源站职责分清：图片、CSS、JavaScript、字体等适合缓存；登录、下单、搜索和个人资料等请求通常需要实时访问源站。

先把访问链路设计清楚

用户请求应先到 CDN 节点，再由 CDN 按规则决定直接返回缓存，还是向源站回源。源站域名不要与对外业务域名混用，可以设置独立的回源域名，并在 DNS 中将业务域名通过 CNAME 指向 CDN 提供的接入地址。

接入时检查三项配置

1. 确认 Host 和证书。CDN 回源时应携带源站能够识别的 Host；如果使用 HTTPS 回源，源站证书的域名也要匹配，不能只在客户端到 CDN 的一段配置证书。
2. 限制源站直接暴露。在防火墙或云安全组中，只允许 CDN 官方公布的回源 IP 段访问 80、443 等必要端口，同时保留管理入口的独立访问策略。
3. 统一协议和跳转。如果用户访问 HTTPS，通常应让 CDN 到源站也使用 HTTPS，避免源站把回源请求再次重定向，造成额外延迟或循环跳转。

这一步是CDN与源站配合的基础。若源站仍允许任何人通过真实 IP 访问，攻击者可以绕过 CDN；若 Host、证书或协议不一致，则会出现 403、证书错误或回源失败。

缓存规则要按内容类型拆分

稳定加速的重点不是“缓存越久越好”，而是让缓存时间与内容变化频率匹配。静态资源可使用较长 TTL，频繁更新的页面则应缩短时间或采用版本号。

源站返回的 Cache-Control、ETag 和 Last-Modified 会影响 CDN 是否缓存及如何验证。对于带 Cookie、Authorization 或 Set-Cookie 的响应，应谨慎处理缓存键。查询参数也要明确规则：商品筛选参数可能必须参与缓存键，而无意义的追踪参数可以统一忽略，减少重复缓存。

把回源压力控制在可承受范围

缓存命中时，源站不需要处理请求；缓存未命中、缓存过期或主动刷新时，CDN 才会回源。如果大量对象同时过期，可能出现“缓存雪崩”。可以采用分批发布、错开过期时间和预热热点文件等方法，避免同一时刻集中回源。

一套可执行的配置顺序

1. 先只接入一个测试域名，确认静态文件、HTML、接口和错误页面的回源结果。
2. 为静态目录设置缓存规则，检查响应头、缓存状态和压缩结果，再逐步扩大匹配范围。
3. 明确不缓存登录、支付、管理后台及含敏感数据的响应，并测试未登录、已登录两种状态。
4. 发布新版本时优先使用带内容指纹的文件名；必须保留原 URL 时，再使用 CDN 刷新或失效功能。
5. 连续观察一段业务高峰和低峰流量，确认源站连接数、响应时间、错误率和回源带宽均在可接受范围内。

如果 CDN 支持源站组，可配置主源站和备用源站，并设置健康检查路径。健康检查页面应只反映应用是否能正常提供服务，不要依赖复杂查询或需要登录的接口。故障切换前还要确认备用源站拥有相同的文件、数据库读能力和证书配置，否则切换后可能只是把错误转移到另一台服务器。

用监控判断问题出在 CDN 还是源站

排查时至少分开观察三类指标：边缘节点响应时间、缓存命中率和回源响应时间。若边缘响应快但回源时间明显升高，重点检查源站应用、数据库或网络；若回源正常而用户访问仍慢，则应检查节点调度、DNS、TLS 握手和大文件传输。

还应记录 4xx、5xx、回源超时和缓存刷新结果。可以用 curl 或浏览器开发者工具查看响应头，但不要只根据一次请求下结论；不同地区、运营商和缓存状态会造成差异。稳定的CDN与源站配合，应通过真实访问日志持续校正规则，而不是接入后长期不调整。

常见问题

CDN 一定要缓存 HTML 吗？

不一定。登录态复杂、内容高度个性化的网站可以先只缓存静态资源，HTML 保持回源，确认数据隔离后再逐步缓存公开页面。

源站 IP 需要完全隐藏吗？

应尽量避免业务域名直接暴露源站地址，并在网络层限制来源。但管理、监控和应急访问仍需保留独立且受控的通道。

文件更新后为什么用户仍看到旧版本？

可能是 CDN 缓存、浏览器缓存或中间代理缓存未失效。优先使用带版本号的文件名；不能改名时，再按对象路径执行刷新。

怎样确认配置真的稳定？

分别从多个地区测试命中和未命中请求，模拟源站短暂不可用，并检查错误页面、回源超时和备用源站切换结果。只有缓存策略、回源链路和故障处理都验证过，CDN与源站配合才算完成。