CDN缓存策略怎么配置？命中率从30%提升到95%的实战经验

目录
先说说CDN的那些关键指标
命中率（Hit Ratio）
回源率（Origin Request Rate）
响应时间
带宽使用情况
命中率低的常见原因和解决方案
缓存策略配置不当
TTL设置太短
源站响应头配置问题
预热不充分
缓存键（Cache Key）设计不合理
CDN节点分布与用户分布不匹配
CDN优化策略详解
AWS CDN托管的缓存策略详细说明
AWS CloudFront 源请求策略详细说明
AWS CloudFront 响应标头策略详细说明
其他一些缓存策略
监控和告警设置
成本优化
常见问题排查
总结
未来趋势与进阶方向
其实CDN优化这事儿，说简单也简单，说复杂也复杂。很多人以为接入个CDN就万事大吉了，结果发现命中率低得可怜，钱花了不少效果却不明显。我之前就遇到过这种情况，CDN命中率只有30%多，简直是在烧钱。客户当时每天CDN流量费用高达数千元，但实际有效请求却少得可怜，大量带宽被浪费在重复回源和无效传输上。后来深入排查才发现，根源在于对CDN缓存机制的认知不足，以及缺乏针对业务特性的精细调优。今天我就把近十年来在多家企业（电商、视频、资讯、游戏）积累的CDN优化经验系统梳理一遍，希望能帮你少走弯路。

先说说CDN的那些关键指标
做CDN优化，你得先知道怎么看数据。就像开车要看仪表盘一样，不然怎么知道车子跑得怎么样？很多人一上来就盲目改配置，结果越调越糟，就是因为没有建立清晰的指标衡量体系。以下是我认为最核心的四个维度的指标，每个都值得你花时间吃透。

命中率（Hit Ratio）
这个是最重要的指标，没有之一。命中率就是CDN直接返回缓存内容的请求占总请求的比例。一般来说，静态资源的命中率应该在90%以上，如果你的命中率只有50-60%，那肯定有问题。但要注意，命中率不是越高越好——如果命中率接近100%，可能说明缓存策略过于激进，导致内容更新不及时，用户看到的是旧数据。理想区间是92%~98%，既能保证大部分请求命中缓存，又能兼顾内容新鲜度。

在AWS CloudFront里查看命中率很简单，进入CloudFront控制台，选择你的分发，然后点击”Monitoring”标签页。这里会显示Cache hit rate的图表，可以看到不同时间段的命中率变化。你也可以通过CloudWatch Metrics获得更细粒度的数据，比如按边缘节点、按时间段（每分钟/每小时）的命中率曲线，这对于定位特定区域或特定时间段的异常非常有用。

回源率（Origin Request Rate）
这个和命中率是相对的，回源率高说明CDN经常要去源站拿数据，这样就失去了CDN的意义。正常情况下回源率应该控制在10%以下。回源率每降低1个百分点，源站的带宽压力和计算开销就能减少约5%~8%，因为回源请求通常伴随着完整的HTTP握手和响应生成。另外，回源率过高还会导致源站日志激增，增加日志存储和解析成本，所以控制回源率不仅是性能问题，也是成本问题。

响应时间
包括CDN响应时间和回源响应时间。CDN响应时间一般应该在100ms以内，如果超过这个数值就要检查是不是节点选择有问题。回源响应时间则取决于源站性能和网络链路，通常建议控制在200ms以内，否则用户感知到的延迟会明显增加。值得一提的是，响应时间与命中率有强关联——命中的请求直接从边缘节点返回，通常只需20~50ms；而回源请求则需要经过源站处理，耗时可能达到200~1000ms，差距可达10倍以上。

带宽使用情况
这个主要是看成本，CDN的费用很大一部分就是带宽费用。通过监控带宽使用情况，可以了解流量分布，优化成本。除了总带宽，还建议关注峰值带宽和95百分位带宽，因为很多CDN计费是按峰值或分位数来算的。如果你发现带宽曲线在某个时段异常陡增，很可能是缓存穿透或热点资源爆发，需要及时介入处理。

在AWS CloudFront的监控面板里，你还能看到：

Origin latency（回源延迟）——衡量源站到边缘节点的网络质量，如果持续偏高，可能是源站部署区域与用户分布区域不匹配。
Error rate（错误率）——包含4xx和5xx错误，其中5xx错误通常表示源站或CDN内部问题，需要立即排查。
Requests（请求数）——反映业务流量趋势，结合命中率可以计算有效缓存请求量。
Bytes downloaded（下载字节数）——实际下发给用户的数据量，与带宽费用直接挂钩。
这些数据都很有用，特别是错误率，如果突然飙升可能是源站出问题了，也可能是你的缓存配置导致源站过载，或者SSL证书过期、域名解析异常等。建议设置错误率告警，当5xx错误率超过0.5%时立即触发通知。

为了让你更直观地理解各项指标的正常范围，这里给出一个通用的参考基准：

指标名称 优秀 良好 需改进 危险
缓存命中率 ≥95% 85%~94% 70%~84% <70%
回源率 ≤5% 6%~15% 16%~30% >30%
平均响应时间（含命中） ≤50ms 51~100ms 101~200ms >200ms
回源响应时间 ≤150ms 151~300ms 301~500ms >500ms
错误率 ≤0.1% 0.1%~0.5% 0.5%~2% >2%

命中率低的常见原因和解决方案
说到命中率低，我遇到过各种奇葩的情况。有些是配置问题，有些是业务设计问题，还有些是源站行为导致。下面我按发生频率从高到低，逐一拆解。

缓存策略配置不当
这是最常见的问题。很多人图省事，直接用默认配置，结果发现很多本该缓存的内容都没有缓存。默认配置通常对所有请求一视同仁，但业务资源有不同的特性——图片、CSS、JS适合长期缓存，而API数据、用户个性化内容则不适合或需要短缓存。如果不做区分，就会导致要么缓存了不该缓存的（数据过期），要么没缓存该缓存的（命中率低）。

比如说，有些动态参数会导致URL不同，CDN就认为是不同的资源。像这种情况：

https://example.com/image.jpg?timestamp=1234567890
https://example.com/image.jpg?timestamp=1234567891
CDN会认为这是两个不同的文件，实际上内容是一样的。解决办法是在CloudFront的Behavior设置里配置Query String参数处理，可以选择忽略某些参数或者只转发特定参数。例如，对于商品详情页的图片，通常只需保留productId参数，而utm_source、sessionId这类跟踪参数完全可以忽略。另外，对于RESTful风格的URL路径，还要注意路径中包含动态ID的情况，这时可以结合路径模式（如/api/v1/products/*）单独设置缓存规则。

TTL设置太短
Time To Live设置太短会导致缓存频繁过期。我见过有人把图片的TTL设置成5分钟，这不是瞎搞吗？静态资源的TTL至少要设置几个小时，甚至几天。但TTL也不是越长越好——如果设置成30天，一旦更新图片或CSS，用户可能要等很久才能看到新版本。所以通常采用”版本化”策略：静态资源文件名包含哈希值（如style.a3f2b1.css），这样内容变化时URL改变，CDN会视为新资源重新缓存，而旧资源继续保留直到过期。这样既保证了命中率，又解决了更新问题。

在CloudFront里可以设置三种TTL：

Minimum TTL：最小缓存时间——即使源站返回Cache-Control: max-age=0，CDN也会至少缓存这个时长（如果设置了）。
Maximum TTL：最大缓存时间——CDN缓存的最长时间，超过后必须回源验证。
Default TTL：默认缓存时间——当源站没有提供缓存头时，使用此值。
一般我会这样设置：

图片、CSS、JS等静态资源：24小时到7天（具体看更新频率，稳定不变的可以设7天）
HTML页面：1-6小时（因为页面结构可能随发布变动，短一些更安全）
API接口：根据业务需求，可能几分钟到几小时（例如商品价格接口可以缓存1分钟，天气数据可缓存10分钟）

源站响应头配置问题
有时候源站返回了不合适的Cache-Control头，比如no-cache或者max-age=0，这会导致CDN不缓存内容。源站配置通常由开发人员维护，他们可能出于安全考虑或调试方便，统一设置了禁止缓存的头部，但上线后忘记改回来。这时候运维需要和开发沟通，明确哪些路径必须缓存，哪些路径必须不缓存。

我之前遇到过一个案例，开发在Nginx配置里给所有静态资源都加了no-cache，结果CDN命中率惨不忍睹。后来改成这样：

location ~* \.(jpg|jpeg|png|gif|css|js)$ {
expires 7d;
add_header Cache-Control “public, immutable”;
}
另外，源站还可能返回Vary: Accept-Encoding或Vary: User-Agent等头部，这会导致CDN根据不同的客户端类型存储多个缓存副本，虽然能提高兼容性，但也会降低缓存利用率。建议只在必要时使用Vary，且尽量使用Vary: Accept-Encoding（只区分压缩方式）而不是更宽泛的字段。

预热不充分
新上线的CDN或者清除缓存后，需要一段时间来”预热”。这期间命中率会比较低，这是正常现象。但如果长时间命中率都上不去，就要检查其他配置了。预热的核心思想是在用户访问之前，主动将热门资源推送到边缘节点。你可以通过编写脚本，模拟用户请求这些资源的URL，让CDN回源并填充缓存。

CloudFront支持手动预热，可以通过Invalidation功能清除缓存，然后用脚本批量访问重要资源来预热缓存。不过要注意，预热期间会产生大量回源流量，建议在业务低峰期进行，同时控制并发数，避免压垮源站。另外，CloudFront还提供了”预取（Pre-fetch）”功能（需结合Lambda@Edge实现），可以在用户访问主页时就提前加载其可能需要的子资源，进一步提升首屏速度。

缓存键（Cache Key）设计不合理
缓存键是CDN区分不同资源的依据，它由URL、Query String、Headers、Cookie等组成。如果缓存键包含太多动态信息，每个用户的请求都会被视为独立资源，命中率必然下降。例如，有些网站在Cookie中存储了用户的省份ID，然后CDN根据省份ID返回不同的广告内容，但这导致同一URL下缓存了多个省份的副本，而每个副本的请求量其实很小。优化思路是：只将真正影响响应内容的参数纳入缓存键，其他参数一律忽略。

CDN节点分布与用户分布不匹配
如果用户集中在东南亚，而你选择的CDN服务商在东南亚节点较少，那么用户请求会被路由到较远的节点（如北美或欧洲），不仅响应时间变长，还会因为节点间缓存不共享导致命中率降低。这种情况在AWS CloudFront中可以通过选择包含更多边缘节点的Price Class来改善，或者使用AWS Global Accelerator来优化路由路径。

CDN优化策略详解
现在说说aws托管的缓存策略。AWS CloudFront提供了丰富的托管策略，极大简化了配置工作，但很多人并不清楚每个策略的适用场景。下面我结合官方文档和实际使用经验，逐一拆解。

AWS CDN托管的缓存策略详细说明

托管缓存策略是AWS预先定义好的一组缓存参数组合，包括TTL范围、缓存键包含哪些内容、是否启用Gzip等。你可以像选择模板一样直接套用，适合大多数常见场景。以下是几个最常用的托管策略及其适用场景：

策略名称 缓存内容 不缓存内容 使用场景
Amplify 缓存大多数静态资源和部分动态内容 不缓存包含特定身份验证头的请求 Amplify应用程序的通用缓存策略
Amplify-Default 缓存静态资源和基于常用头部的内容，保留某些Cookie 不缓存带有特定认证头的请求，某些动态API响应 Amplify应用的标准配置，平衡缓存与个性化
Amplify-Default-V2 与Amplify-Default类似，但有优化的TTL设置 与Amplify-Default类似 需要改进的缓存性能的Amplify应用
Amplify-DefaultNoCookies 缓存静态资源和页面内容 不缓存任何Cookie信息，不缓存认证请求 不需要基于Cookie区分用户的Amplify应用
Amplify-DefaultNoCookies-V2 与DefaultNoCookies类似，但有更长的TTL 与DefaultNoCookies类似 追求更高缓存命中率的静态Amplify应用
Amplify-ImageOptimization 缓存图像文件(jpg, png, gif等)，支持不同的图像格式 不缓存非图像内容，不保留大多数请求头 图像密集型网站，图片库，电商产品展示
Amplify-ImageOptimization-V2 与ImageOptimization类似，增加了WebP等现代格式支持 与ImageOptimization类似 需要现代图像格式支持的应用
Amplify-StaticContent 缓存JS, CSS, 字体, 图像等静态资源，长TTL 不缓存HTML或动态内容，不保留Cookie 静态资源的长期缓存，提高重复访问性能
Amplify-StaticContent-V2 与StaticContent类似，但有更优化的压缩设置 与StaticContent类似 需要最佳静态资源性能的应用
CachingDisabled 不缓存任何内容 所有内容都直接从源站获取 实时数据，个性化内容，需要实时源站响应的场景
CachingOptimized 缓存大多数内容，启用压缩，优化TTL 不缓存POST/PUT请求，特定动态API路径 通用Web应用，需要平衡缓存与新鲜度的场景
CachingOptimizedForUncompressedObjects 缓存未压缩的对象，自动应用适当的TTL 不缓存已经压缩的内容，不处理某些动态请求 源站不提供压缩的情况，CDN负责压缩
Elemental-MediaPackage 缓存视频分段，流媒体清单文件 不缓存用户特定的媒体请求，认证令牌 视频流媒体，直播，点播视频服务
UseOriginCacheControlHeaders 根据源站的Cache-Control头决定缓存行为 如果源站指示不缓存，则不缓存；忽略查询参数 源站已有完善缓存策略的情况
UseOriginCacheControlHeaders-QueryStrings 根据源站Cache-Control头和URL查询参数缓存 如源站指示不缓存则不缓存 基于查询参数提供不同内容且源站控制缓存的场景
除了托管策略，你还可以创建自定义缓存策略，精细控制缓存键的组成部分。例如，你可以决定是否包含以下内容：
– 查询字符串（全部、指定列表或忽略全部）
– HTTP请求头（如Accept-Language、User-Agent等）
– Cookie（全部、指定名称或忽略）
– 设备类型（通过CloudFront-Device-Type头部）

需要特别注意的是：缓存键越”粗”，命中率越高，但内容差异性越差；缓存键越”细”，个性化越强，但命中率越低。建议优先使用”忽略所有查询字符串”的策略，只对确实需要区分参数的路径单独配置。

AWS CloudFront 源请求策略详细说明

源请求策略与缓存策略是配套使用的。缓存策略决定如何生成缓存键和缓存时长，而源请求策略决定当缓存未命中时，向源站转发哪些客户端请求信息。这两者的关系有点像”图书馆借阅规则”和”图书采购申请单”——缓存策略规定哪些书可以外借、借多久，源请求策略则规定当图书馆缺书时，如何向总馆申请调书，需要提供哪些信息。

策略名称 转发内容 不转发内容 使用场景
AllViewer 转发所有查看者请求参数，包括查询字符串、标头和Cookie 不限制任何参数的转发 需要将所有客户端请求信息传递给源站的场景，适用于高度依赖客户端信息的动态内容
AllViewerAndCloudFrontHeaders-2022-06 转发所有查看者请求参数和截至2022年6月的所有CloudFront标头 不限制任何参数或CloudFront标头的转发 需要完整客户端信息以及CloudFront添加的信息(如设备类型、地理位置)的场景
AllViewerExceptHostHeader 转发除Host标头外的所有查看者请求参数 不转发Host标头 当源站需要使用不同的主机名处理请求，但仍需其他所有客户端信息的场景
CORS-CustomOrigin 转发与CORS(跨源资源共享)相关的标头到自定义源 不转发与CORS无关的其他标头 需要支持跨域请求的自定义源站(非S3)场景，如API或Web应用
CORS-S3Origin 转发与CORS相关的标头到S3源 不转发与CORS无关的其他标头 需要支持跨域请求的S3存储桶场景，如从浏览器直接访问S3资源
Elemental-MediaTailor-PersonalizedManifests 转发Elemental MediaTailor个性化清单所需的标头 不转发与媒体个性化无关的标头 视频流媒体场景，特别是需要个性化内容或广告插入的流媒体服务
HostHeaderOnly 仅转发Host标头到源站 不转发任何其他查看者请求参数 简单的静态内容分发场景，源站仅需要知道请求的主机名
UserAgentReferrerHeaders 转发User-Agent(用户代理)和Referer(引用页)标头到源站 不转发其他查看者请求参数 源站需要了解访问者浏览器类型和来源网站的场景，如内容适配或引用统计
这些源请求策略控制CloudFront将哪些信息从查看者(客户端)请求中转发到源站。选择合适的策略可以优化源站请求处理，减少不必要的信息传递，同时确保源站获得所需的上下文信息来正确响应请求。例如，如果你的源站需要根据Accept-Language返回不同语言的内容，那么必须选择包含该头部的策略；但如果源站是S3静态托管，则完全不需要转发任何头部，使用Managed-NoHeaders即可，这样可以减少请求头的大小，加快传输速度。

AWS CloudFront 响应标头策略详细说明

响应标头策略则是在CDN返回响应给客户端时，添加、修改或删除某些HTTP头部。它不直接影响缓存命中率，但对安全性和跨域功能至关重要。

策略名称 添加/修改内容 不添加/不修改内容 使用场景
CORS-and-SecurityHeadersPolicy 添加CORS相关标头和安全标头到响应中 不修改源站提供的其他标头 需要同时支持跨域请求和增强安全性的Web应用，如需要跨域访问的API且需要防XSS、点击劫持等安全保护
CORS-With-Preflight 添加CORS相关标头并支持预检(OPTIONS)请求 不添加安全标头，不修改源站提供的其他标头 需要支持复杂跨域请求的场景，特别是涉及非简单请求(如带自定义标头或使用PUT/DELETE方法)的API
CORS-with-preflight-and-SecurityHeadersPolicy 添加CORS相关标头(含预检支持)和安全标头 不修改源站提供的其他标头 需要全面CORS支持(包括复杂请求)和安全增强的Web应用，如SPA(单页应用)与后端API交互
SecurityHeadersPolicy 仅添加安全相关标头到每个响应 不添加CORS标头，不修改源站提供的其他标头 注重安全性但不需要跨域支持的网站，如企业内部应用或对安全有高要求的公共网站
SimpleCORS 仅添加基本CORS标头，支持简单跨域请求 不添加安全标头，不支持预检请求，不修改源站提供的其他标头 只需基本跨域支持的简单场景，如只允许GET请求的公共API或静态资源
这些响应标头策略控制CloudFront如何修改从源站返回给客户端的HTTP响应标头。适当的策略可以增强Web应用的安全性，启用跨域资源共享功能，而无需修改源站配置。安全标头通常包括内容安全策略(CSP)、X-XSS-Protection、X-Frame-Options等，用于防止常见的Web安全威胁。例如，添加X-Content-Type-Options: nosniff可以防止浏览器对MIME类型的猜测攻击；添加Strict-Transport-Security可以强制浏览器使用HTTPS访问，提升安全性。

当然要是这些不满足还可以自定义！！AWS允许你完全自定义上述三种策略，你可以通过CloudFront控制台或AWS CLI创建自己的策略，然后关联到特定的Behavior上。自定义时要注意策略之间的兼容性，比如缓存策略中忽略Cookie，但源请求策略中又转发Cookie，这会导致源站收到不一致的信息，可能造成异常。

其他一些缓存策略
除了AWS官方提供的托管策略，在实际运维中，我还会结合业务特点采用以下几种缓存优化手段：

分层缓存策略 不同类型的资源用不同的缓存策略。我一般会创建多个Behavior，针对不同的路径模式设置不同的缓存规则：

/api/* – TTL: 5分钟，转发所有参数
/images/* – TTL: 7天，忽略查询参数
/css/* – TTL: 1天，启用压缩
/js/* – TTL: 1天，启用压缩
/* – TTL: 1小时，默认行为
这种分层设计的好处是：图片和样式表可以设置超长TTL（比如7天），而HTML页面可以设置中等时长（1小时），API接口则设置极短时长（5分钟）甚至不缓存。通过路径匹配，你可以精细控制每个资源类型的缓存行为，而不是一刀切。

启用压缩 CloudFront支持自动压缩，可以显著减少传输数据量。在Behavior设置里开启”Compress Objects Automatically”就行了。不过要注意，压缩会消耗一些CPU资源，对于已经压缩过的文件（如图片）就没必要再压缩了。CloudFront默认支持Gzip和Brotli压缩，Brotli比Gzip压缩率更高（通常再小15%~20%），但要求客户端支持。建议同时开启两者，CDN会根据客户端的Accept-Encoding头部自动选择最优方式。

合理使用Origin Shield 这是CloudFront的一个高级功能，相当于在CDN和源站之间加了一层缓存。对于回源比较频繁的场景很有用，可以减少源站压力。Origin Shield实际上是一个集中式的”上层缓存层”，所有边缘节点回源时先请求Origin Shield，如果Origin Shield有缓存则直接返回，只有Origin Shield未命中时才真正回源。这在多边缘节点场景下效果尤为明显，能有效避免多个边缘节点同时回源导致的”惊群效应”。

我在一个视频网站项目中用过Origin Shield，效果很明显。因为视频文件比较大，用户分布又比较集中，开启Origin Shield后回源请求减少了60%多。而且视频源站是自建的Nginx集群，回源压力大幅降低后，我们甚至缩减了一半的源站服务器，节省了不少成本。

HTTP/2和HTTP/3支持 现在的CDN基本都支持HTTP/2了，CloudFront也不例外。HTTP/2的多路复用特性可以显著提升页面加载速度，特别是对于有很多小文件的网站。而HTTP/3基于QUIC协议，进一步降低了连接建立延迟，在弱网环境下表现更优。CloudFront在2023年已全面支持HTTP/3，你只需在分发设置中启用即可，无需修改源站。启用后，移动端用户的首包时间平均减少约30%。

智能路由 CloudFront会自动选择最优的边缘节点，但有时候你可能需要手动干预。比如某些地区的节点质量不好，可以通过地理位置限制来避免使用这些节点。你也可以结合AWS的Route 53进行DNS级别的流量调度，将不同区域的用户指向最合适的CloudFront分发。

静态资源与动态资源分离 这是最基础但最有效的手段之一。将图片、CSS、JS、字体、视频等静态资源托管在CDN，而动态接口直接走源站（或通过API网关）。如果不得不让动态内容也经过CDN，可以设置很短的TTL（如1~5分钟），并开启Cache-Control: must-revalidate，确保数据不会过时。

AWS CloudFront的一些实用技巧

用了这么久CloudFront，发现了一些比较实用的技巧，这些技巧很多是文档里没有详细说明的，是我在实际踩坑中总结出来的。

Lambda@Edge 这个功能很强大，可以在CDN边缘节点运行代码。我用过几个场景：A/B测试、URL重写、权限验证、设备检测、图片格式转换等。Lambda@Edge的延迟开销通常只有几毫秒，几乎不影响整体响应时间，但能实现非常灵活的定制化逻辑。

比如这个检测WebP支持的例子：

exports.handler = (event, context, callback) => {
const request = event.Records[0].cf.request;
const headers = request.headers;

const accept = headers.accept && headers.accept[0] && headers.accept[0].value;

if (accept && accept.includes(‘image/webp’)) {
request.uri = request.uri.replace(/\.(jpg|jpeg|png)$/i, ‘.webp’);
}

callback(null, request);
};
这个函数在origin-request阶段运行，根据客户端的Accept头部判断是否支持WebP，如果支持则在回源请求中添加相应的格式偏好，源站根据这个偏好返回WebP图片。这样就不需要在客户端引入额外的JS库来检测，减少了前端复杂度。

除了图片格式转换，我还用Lambda@Edge实现过：
– 地域重定向：根据客户端IP所在国家，自动跳转到对应的语言站点（如example.com -> example.co.jp）
– 访问频率限制：在边缘节点对单个IP的请求频率进行限流，防止DDoS和爬虫过度消耗
– 自定义鉴权：对接第三方身份认证服务，在边缘节点完成Token校验，通过后再回源，有效减轻源站压力
– 响应头动态修改：根据请求参数动态设置Cache-Control，比如对带?debug=1的请求返回no-cache，方便调试

实时日志分析 CloudFront可以把访问日志实时推送到Kinesis Data Streams，然后用Lambda处理。我用这个功能做过实时监控，当错误率超过阈值时自动发送告警。相比传统的批处理日志分析（如S3 + Athena），实时流式分析能更快发现异常，尤其适合大促活动期间的秒级监控。

除了Kinesis，你也可以将日志直接输出到S3，然后使用Amazon Athena进行交互式查询。我建议同时保留两种方式——S3用于长期归档和趋势分析，Kinesis用于实时告警和突发事件排查。

多源站配置 CloudFront支持配置多个源站，可以实现负载均衡和故障转移。我一般会配置主源站和备用源站，当主源站出问题时自动切换到备用源站。你还可以为不同路径指定不同源站，例如图片从S3获取，而动态API从EC2获取，这样架构更清晰。

多源站配置时要注意源站优先级和权重设置，CloudFront支持按权重分配回源流量，你可以将70%的流量指向主源，30%指向备源，用于灰度发布或压力测试。

自定义错误页面 通过配置Custom Error Pages，可以为不同的HTTP错误码返回自定义页面。这样用户体验会好很多，而且可以减少无效的回源请求。例如，当某个资源404时，如果不设置自定义页面，CDN会回源去拿源站的404页面，这会产生一次不必要的回源。如果直接缓存一个轻量级的自定义404页面，就能节省回源成本。

我还会为503错误（源站不可用）配置一个友好的”系统维护中”页面，并设置较长的缓存时间（如10分钟），这样在源站恢复之前，用户至少能看到一个明确的提示，不会一直等待超时。

使用地理限制（Geo Restriction） CloudFront支持按国家/地区允许或阻止访问。如果你的业务只服务于特定地区，可以在分发级别设置白名单，阻止其他地区的请求，从而减少无意义流量和攻击风险。此外，地理限制还能避免因非目标地区用户访问导致缓存污染（例如，来自不同国家的用户可能触发不同语言版本内容的缓存，但实际你只需要一种）。

监控和告警设置
CDN优化不是一次性的工作，需要持续监控和调优。很多团队只在部署CDN时配置一次，之后就很少关注，直到线上出问题才发现命中率已经跌到谷底。

CloudWatch监控 CloudFront的所有指标都会推送到CloudWatch，可以设置各种告警：

命中率低于阈值告警（比如低于80%持续5分钟）
错误率超过阈值告警（比如5xx错误超过1%）
回源延迟过高告警（比如超过500ms）
带宽使用异常告警（突然飙升或骤降）
我一般会设置这些告警规则：

命中率 < 85% 持续10分钟 -> 发送告警
4xx错误率 > 5% 持续5分钟 -> 发送告警
5xx错误率 > 1% 持续5分钟 -> 发送告警
回源延迟 > 2秒 持续5分钟 -> 发送告警
除了指标告警，还可以设置复合告警（Composite Alarms），例如当命中率低且回源率高同时出现时，才触发严重级别告警，减少误报。另外，建议在告警动作中绑定SNS主题，将告警消息推送到邮件、短信、Slack或PagerDuty，确保相关人员及时收到。

第三方监控工具 除了CloudWatch，我还会用一些第三方工具来监控CDN性能，比如Pingdom、GTmetrix等。这些工具可以从用户角度测试网站性能，发现一些CloudWatch监控不到的问题。例如，CloudWatch显示某个边缘节点响应时间正常，但实际从某地电信网络访问却非常慢，这可能是ISP路由问题，第三方拨测工具就能发现。

此外，我也会在网站前端集成RUM（Real User Monitoring）工具，比如AWS CloudWatch RUM或商业工具如Dynatrace，收集真实用户的性能数据，包括首字节时间、DOM加载时间等，并与CDN指标关联分析，从而定位性能瓶颈到底在CDN层、网络层还是源站层。

日志审计与定期巡检 建议每周进行一次CDN配置和指标的巡检，检查是否有配置漂移、是否有新的异常模式。可以使用AWS Config规则来检测CloudFront配置是否偏离了基线，比如TTL是否被人为改小、是否禁用了压缩等。

成本优化
CDN的费用不便宜，特别是流量大的网站。很多运维只关注性能而忽视成本，但其实通过合理优化，在不牺牲用户体验的前提下，完全能节省30%~50%的CDN开销。

Price Class选择 CloudFront有三个价格等级，包含的边缘节点数量不同。如果你的用户主要在北美和欧洲，选择Price Class 100就够了，没必要选择包含全球所有节点的Price Class All。因为节点越多，AWS运营成本越高，自然单价也更贵。具体选择策略：

Price Class 覆盖区域 适用场景 成本对比
Price Class 100 北美 + 欧洲 用户集中在欧美地区 基准（最便宜）
Price Class 200 北美 + 欧洲 + 亚洲（部分） 用户分布在欧美和东亚 约贵15%~25%
Price Class All 全球所有边缘节点 用户遍布全球，包括南美、大洋洲、非洲等 约贵30%~40%
我的建议是：先根据业务用户分布选择，如果用户集中在国内（但国内无节点）则选择包含亚太节点的Price Class 200；如果业务全球化且对延迟敏感，再考虑Price Class All。另外，价格等级可以在不中断服务的情况下随时更改，所以你可以先选便宜的，然后通过监控观察响应时间是否达标，再决定是否升级。

缓存策略优化 提高命中率不仅能改善性能，还能降低成本。因为CDN的费用主要是按流量计算的，命中率高意味着回源流量少，总体费用就低。如果命中率低就会出现流量放大效应：
• 正常命中率80%：1GB实际需求 = 1.25GB CDN流量（因为回源只占20%，但回源流量也计入CDN传出流量）
• 当前命中率可能<20%：1GB实际需求 = 5GB+ CDN流量（因为回源请求每次都需要从源站完整拉取，并且可能多次回源）

举例来说，一个每天实际用户请求数据量100GB的网站，当命中率只有20%时，CDN需要从源站拉取80GB数据，加上向用户传输的100GB，总传出流量为180GB，费用是实际需求的1.8倍。而命中率提升到90%后，回源仅需10GB，总传出流量降为110GB，成本直接下降39%。所以，花精力优化命中率，就是直接省钱。

压缩和格式优化 启用压缩可以减少传输数据量，WebP格式的图片比JPEG小30-50%。这些优化都能直接降低CDN费用。除了图片，还可以对CSS、JS、HTML等文本资源开启Brotli压缩（比Gzip压缩率高20%左右）。建议在源站就提前压缩好静态资源，然后让CDN直接发送压缩后的内容，避免CDN实时压缩带来的CPU开销。

我之前优化过一个图片网站，通过启用压缩和WebP转换，CDN费用降低了40%多。具体做法是：用Lambda@Edge检测客户端是否支持WebP，若支持则回源请求时添加format=webp参数，源站（S3）通过预置的WebP版本返回；同时对所有文本资源启用Brotli压缩。两个月下来，账单从每月$5000降到了$2800左右。

使用预留容量或承诺用量 如果你的CDN流量非常稳定且规模较大，可以考虑与AWS签署企业级折扣协议（EDP）或承诺每月最低用量，这样可以获得更低的单价。虽然这需要一定的承诺和前期沟通，但对于年流量超过100TB的业务来说，节省的金额相当可观。

清理无用缓存 定期清理那些不再被访问的旧版本资源（比如已下线的活动页面、过期图片），可以减少CDN的存储费用（如果启用了边缘存储）。另外，使用Invalidation API清除无效缓存时，要批量操作，因为每次Invalidation请求有数量限制（最多1000个路径），超出部分会额外收费。

常见问题排查
做CDN优化经常会遇到各种问题，分享几个排查思路和实用命令。

缓存不生效 首先检查响应头，看看有没有Cache-Control、Expires等缓存相关的头。然后检查CloudFront的Behavior配置，确认TTL设置正确。

可以用curl命令测试：

curl -I https://your-domain.com/test.jpg看响应头里的X-Cache字段，Hit表示命中缓存，Miss表示没有命中。如果看到X-Cache: Miss from cloudfront，说明未命中。你还可以加上-H “Cache-Control: no-cache”来模拟强制刷新的请求，观察CDN的行为。

如果X-Cache显示Miss，但你又确信文件应该被缓存，可以检查响应头中的Age字段——它表示对象已经在边缘节点缓存了多长时间（秒）。如果Age为0，说明刚回源拿到的；如果Age不断增长，说明正在缓存中。

某些地区访问慢 可能是CDN节点选择有问题。用不同地区的VPS测试访问速度，确定是哪些地区有问题。然后检查是不是需要调整Price Class或者配置地理位置限制。你还可以使用CloudFront的”CloudFront Map”工具（第三方网站）查看各个边缘节点的IP和响应时间。

另外，DNS解析也可能影响访问速度。如果你使用的是第三方DNS服务，确保其具有全球智能解析能力，能将用户引导到最近的CloudFront边缘节点。AWS Route 53的延迟路由策略（Latency Routing）可以配合CloudFront使用，进一步优化路由。

缓存穿透 如果某个资源一直无法缓存，可能是URL参数或者响应头有问题。检查是不是有随机参数，或者源站返回了no-cache头。典型的缓存穿透场景包括：
– 每个请求都带时间戳或随机数（如?t=1234567890）
– 源站返回Cache-Control: private, no-store
– CDN配置中Minimum TTL为0且源站未指定缓存头

我遇到过一个奇葩问题，开发在图片URL后面加了随机数防止缓存，结果CDN命中率为0。后来改成用版本号，问题就解决了。具体是：将image.jpg?rand=123改为image_v123.jpg，这样URL变化但路径固定，CDN能很好地缓存每个版本。

回源请求过多导致源站压力大 如果命中率尚可但回源请求仍然很多，可以检查是否有热点资源频繁过期。比如某个资源TTL设为1小时，但每10分钟就有大量用户访问，导致在过期前的一段时间内缓存是有效的，但过期瞬间大量请求同时回源。解决方法：适当延长TTL，或者启用Origin Shield来聚合回源请求。

SSL证书相关问题 CloudFront支持自定义SSL证书，但如果你使用的是AWS提供的证书（通过ACM），需要确保证书覆盖了你要使用的域名，并且域名在CloudFront分发的别名（CNAME）列表中正确配置。SSL证书过期会导致CDN节点无法响应HTTPS请求，错误率会突然飙升。建议在ACM中开启自动续期，并设置证书到期前30天的告警。

边缘节点IP变更 CloudFront的边缘节点IP地址会不定期变化，如果你的源站防火墙或安全组只允许特定IP访问，可能会因为IP变更导致回源失败。最佳实践是使用AWS提供的IP地址范围列表（ip-ranges.json）动态更新安全组，而不是手动添加固定IP。

总结
CDN优化是个系统工程，需要从多个维度来考虑。命中率是最重要的指标，但不是唯一的指标。要结合业务特点，制定合适的缓存策略。同时，优化不是一锤子买卖，需要持续监控、定期复盘，根据业务变化调整配置。

AWS CloudFront功能很强大，但配置也比较复杂。建议先从基础配置开始，逐步优化。不要一开始就搞得很复杂，容易出问题。我个人的实践路径是：先确保静态资源命中率≥90%，再逐步优化动态内容的缓存策略，最后通过精细化监控和自动化手段固化成果。

最重要的是要持续监控和优化，CDN不是配置好就不管了。用户行为会变化，业务需求也会变化，CDN策略也要跟着调整。例如，大促活动期间流量激增，需要提前预热；活动结束后又要清理过期的资源，避免缓存污染。

我现在维护的几个网站，CDN命中率都在95%以上，用户访问速度提升了3-5倍。虽然前期折腾了不少时间，但效果还是很明显的。而且随着AWS不断推出新功能（比如更智能的缓存策略、支持QUIC等），优化空间还在持续增大。

未来趋势与进阶方向
展望未来，CDN正在从单纯的”内容分发”向”边缘计算平台”演进。以下几个方向值得关注：

边缘计算与Serverless融合：Lambda@Edge和CloudFront Functions让开发者可以在边缘节点运行轻量级逻辑，未来会有更多业务逻辑（如个性化推荐、实时数据处理）下沉到边缘，进一步减少回源需求。

AI驱动的自适应缓存：通过机器学习分析用户访问模式，自动调整TTL和缓存策略，不再需要人工设置。AWS已经推出了CloudFront Cache Optimization的建议功能，未来会越来越智能。

QUIC/HTTP/3普及：随着HTTP/3的标准化和客户端支持度提升，CDN的传输延迟将进一步降低，尤其是在移动和弱网环境下，用户体验会有质的飞跃。

多CDN混合架构：越来越多的企业开始采用多云或混合CDN策略，通过智能调度在多个CDN服务商之间切换，实现容灾和成本最优。这对运维提出了更高的要求，但也带来了更大的灵活性和可靠性。

安全与加速一体化：CDN不仅加速内容，还集成WAF、DDoS防护、Bot管理等功能，形成”安全加速”的统一边缘层。未来，安全策略也将与缓存策略深度联动，比如对可疑请求直接返回缓存页而不回源，减少攻击对源站的影响。