其实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%时立即触发通知。

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

命中率低的常见原因和解决方案

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

缓存策略配置不当

这是最常见的问题。很多人图省事，直接用默认配置，结果发现很多本该缓存的内容都没有缓存。默认配置通常对所有请求一视同仁，但业务资源有不同的特性——图片、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等。你可以像选择模板一样直接套用，适合大多数常见场景。以下是几个最常用的托管策略及其适用场景：

除了托管策略，你还可以创建自定义缓存策略，精细控制缓存键的组成部分。例如，你可以决定是否包含以下内容：
- 查询字符串（全部、指定列表或忽略全部）
- HTTP请求头（如Accept-Language、User-Agent等）
- Cookie（全部、指定名称或忽略）
- 设备类型（通过CloudFront-Device-Type头部）

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

AWS CloudFront 源请求策略详细说明

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

这些源请求策略控制CloudFront将哪些信息从查看者(客户端)请求中转发到源站。选择合适的策略可以优化源站请求处理，减少不必要的信息传递，同时确保源站获得所需的上下文信息来正确响应请求。例如，如果你的源站需要根据Accept-Language返回不同语言的内容，那么必须选择包含该头部的策略；但如果源站是S3静态托管，则完全不需要转发任何头部，使用Managed-NoHeaders即可，这样可以减少请求头的大小，加快传输速度。

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

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

这些响应标头策略控制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 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正在从单纯的"内容分发"向"边缘计算平台"演进。以下几个方向值得关注：

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

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

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

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

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