很多朋友一提到“阿里云 CDN”第一反应就是“给网站开个缓存加速”然后到控制台把域名一加、CNAME 一解析就以为完事了。等到线上出现“图片刷不出来”“接口数据老是旧”“源站带宽被打满”这些问题时才开始回头研究 CDN 到底干了什么。我自己前几年也被这些事折磨过今天就把这几年的实操经验整理一遍从回源策略、缓存规则、HTTPS 证书续期、OSS 私有回源到和 ECS、K8s、Maven 镜像这些场景的配合一次性说清楚。这篇文章适合谁看两类人最合适一是刚接手公司站点、想用 CDN 给网站或接口做加速的运维开发二是已经被 CDN 缓存穿透、证书过期、回源失败折磨过想系统补一补底层逻辑的同行。文章不堆概念重点讲操作判断和部署链路里的那些“为什么”。1. CDN 到底在链路里扛什么活先想清楚再动手1.1 CDN 不是“缓存开关”而是流量分层的第一道闸门很多人在配置 CDN 时默认它就是一个大号缓存源站要是不更新就使劲刷新缓存。这个理解太浅了。CDN 在架构里真正的作用是“流量分层”把用户可以就近访问的静态资源、下载包、图片视频这些冲抵到边缘节点回源量降下来源站压力就小了真正需要实时数据的动态请求则通过“绕过缓存”或者“不缓存只加速链路”的方式走最优路径回源。所以第一步得先想清楚你的业务适合 CDN 全站加速还是只加速静态资源如果你是个 WordPress 博客全站 CDN 没问题如果你是个管理后台接口全部带用户态信息那全站套 CDN 可能反而引入一堆“缓存错乱”问题。最好的做法是给静态资源单独划一个域名比如 static.example.com、img.example.comCDN 只管这些域名主站 API 不套 CDN 或者只做“动态加速”。我见过一个比较典型的出问题案例有团队把主站 HTML、API 接口全配置了 CDN只图省事结果用户在后台改了个头像前端页面刷新后还是老图。排查到最后发现是 HTML 也被 CDN 缓存了 10 分钟。网页本身缓存 10 分钟问题不大但接口缓存了 10 分钟用户体验就非常差了。所以配置 CDN 前先做资源分类这点比任何参数都重要。1.2 从阿里云控制台的“域名管理”看整个 CDN 工作边界阿里云 CDN 控制台里最核心的入口就是“域名管理”。添加域名时有个关键概念叫“加速域名”它和“源站”是两个独立的实体。加速域名是用户在浏览器里访问的那个域名源站是这个域名背后的真实服务器或存储桶。CDN 节点就是在这两者之间做了“内容缓存 链路加速”。官方还区分“图片小文件”“大文件下载”“视音频点播”“全站加速”这几个业务场景它们的区别不是简单勾选而是节点上默认的缓存策略、分片策略、Range 回源行为不一样。比如视频点播会默认启用 Range 回源和分片缓存避免用户拖进度条时把整个文件拉回源站而图片小文件场景会默认缓存带参数或不带参数的 URL这个要看业务设置。创建加速域名时选择场景其实是让 CDN 在底层自动套了一套推荐参数之后你还能手动微调。顺带说一个很多人忽略的点在阿里云上配置 CDN 加速域名时如果源站是 OSS Bucket你可以直接在下拉框里选中该 Bucket这样平台会自动帮你把回源 HOST 设置为 Bucket 的默认域名省掉很多回源鉴权问题。如果源站是 ECS 或 SLB那你得手动写清楚站点域名和回源协议后面我会细讲。2. 回源配置一切缓存命中的前提都在这2.1 回源 HOST 和源站地址的“错位”陷阱这是排查 CDN 问题时最高频的坑。很多人创建完 CDN 加速域名之后发现源站 ECS 上的 Nginx 收到的 HTTP Host 头不对导致虚拟主机配置不生效直接返回 403 或默认站点。原因在于 CDN 回源时有三个地址概念加速域名用户访问的域名比如 cdn.example.com。源站地址CDN 回源时连接的 IP 或域名可以是 ECS 公网 IP、SLB 域名、OSS 域名。回源 HOSTCDN 回源时实际放在 HTTP Header 里的 Host 字段。默认情况下回源 HOST 会继承加速域名。但很多源站服务器的 Nginx 配置里根本没有这个加速域名的 server_name于是 CDN 请求落到 Nginx 时匹配不到对应 server 块就返回了默认站点或直接 403。解决办法很朴素要么在 Nginx 里把加速域名加到 server_name 里要么在阿里云 CDN 的“回源配置”里把回源 HOST 改成源站真正能识别的域名。我个人的建议是在 CDN 上把回源 HOST 显式配置为源站域名这样源站的所有重定向、日志分析、HTTPS 证书校验都保持一致排查问题时心智负担小很多。2.2 多源站轮询和主备切换的配置逻辑阿里云 CDN 支持在同一个加速域名下配置多个源站地址可以设置不同的权重和优先级。这是一个非常实用的容灾手段。举个例子我有两个 ECS 实例分别承载同样的静态文件正常情况下 CDN 会按权重轮询访问两个源站。如果其中一台宕机CDN 节点回源失败后会自动切换到另一台这个过程对用户无感。配置时要注意几点源站地址如果是域名CDN 回源时会解析这个域名解析结果的变化 CDN 不一定实时感知所以源站 IP 变更后最好在 CDN 控制台手动“主动更新”一下。如果需要停服维护某台源站不要直接在 ECS 上关掉 Nginx这样 CDN 回源会报 502/504。优先在 CDN 配置里把该源站“禁用”或者在 SLB 层面摘除后端这样切流更平滑。我遇到过一次诡异故障一台源站 Nginx 还在运行但磁盘被日志打满了导致返回 500 错误。CDN 回源拿到 500边缘节点默认不会缓存用户的请求全部透传回源结果整站接口都卡。后来我在 CDN 上给源站配了“4XX/5XX 状态码缓存”规则把 502 和 504 分别缓存 5 秒和 10 秒一下就稳住了。这种细节在控制台里很容易被忽略但关键时刻非常管用。2.3 回源协议和端口HTTP 与 HTTPS 二选一还是跟随阿里云 CDN 回源协议有三种选择HTTP、HTTPS、跟随。默认是“跟随”也就是用户请求用 HTTPS回源就用 HTTPS用户请求用 HTTP回源就用 HTTP。这看起来合理但有个隐患如果用户通过 HTTPS 访问 CDNCDN 需要以 HTTPS 回源到你的源站 Nginx那源站的 SSL 证书必须有效且匹配回源 HOST否则握手失败。所以很多生产环境会刻意把“回源协议”改成 HTTP让 CDN 到源站这段走明文反正内网或安全组层面做限制就行。这样做的好处是源站不用为 CDN 回源单独准备证书也少一层 TLS 握手开销。缺点是源站和 CDN 之间的数据是明文传输如果你的源站和 CDN 节点之间跨越公网且业务数据敏感这种配置就要斟酌。我的建议是如果源站部署了正规证书回源协议可以直接选“跟随”如果源站只是在测试环境或者源站证书已经快过期没来得及换可以临时改成 HTTP 保业务。等证书更新完再切回跟随。这个切换在控制台是即时生效的不用等节点刷新。3. 缓存配置不是 TTL 越长越好要理解缓存键3.1 TTL 分层目录、文件后缀、URI 规则各自管什么阿里云 CDN 的缓存配置支持三种粒度目录如 /wp-content/uploads/、文件后缀如 .jpg;.png;.css;.js、全路径如 /api/version.json。很多人在“文件后缀”里一股脑把 .html、.php、.jsp 都设成几小时缓存这是很危险的。动态页面如果设置了强制缓存用户看到的内容就会是旧的。我习惯的分层策略是这样的图片、CSS、JS 等带 hash 版本号的静态资源TTL 设置 30 天因为文件名内容变了 hash 就变浏览器和 CDN 都会当成新资源来请求。** HTML 页面**TTL 设置 3 到 5 分钟既保证 CDN 能缓解一部分回源压力又不会让页面内容滞后太久。接口 JSON 数据除非你能在源站控制好 Cache-Control否则建议设置“不缓存”或者“缓存 1 分钟”。很多后端接口没有主动带 Cache-Control 头CDN 默认会遵循源站的缓存头如果源站什么都没返回CDN 可能会按控制台兜底策略缓存造成数据延迟。还有个细节如果你在源站 Nginx 上返回了Cache-Control: no-cache阿里云 CDN 默认会遵循源站响应头不会缓存该资源但如果控制台里配置了“强制缓存”且 TTL 大于 0CDN 可能忽略源站头。所以排查“为什么我明明改了源站 Cache-ControlCDN 还是缓存旧数据”时先去控制台看是不是命中“强制缓存”。3.2 过滤参数、缓存 Key 和 URL 重写缓存 Key 是 CDN 缓存系统区分不同内容的依据默认情况下一个完整的 URL 就是一个 Key。问题是很多业务 URL 里带有跟踪参数或随机参数比如?fromwechatutm_sourcexxx这些参数一变CDN 就会认为是一个全新请求导致同一个图片被缓存了 N 份命中率大幅下降。解决办法有两个过滤参数打开“过滤参数”开关后CDN 会忽略 URL 问号后的全部参数所有?x1和?x2都会命中同一份缓存。适合图片、CSS、JS 这类不依赖参数的静态资源。保留指定参数如果你只有少数几个参数会影响内容比如?langzh和?langen返回不同内容那就在“缓存 Key 设置”里配置只保留 lang 参数其他参数过滤掉。URL 重写这个功能我也经常用。比如源站实际文件路径是/static/images/a.jpg但用户访问的是/images/a.jpg我可以在 CDN 上做 URL 重写CDN 回源时自动把/images/重写为/static/images/源站不用为了适配 CDN 去改目录结构。这个功能在应用迁移时特别有用比如老站点的文章图片路径是/uploads/2022/...新系统改成了/_assets/upload/...CDN 上重写一下就能实现平滑过渡。3.3 缓存命中率理想值是多少低命中率怎么定位“缓存命中率”是 CDN 运维里最重要的健康指标之一。阿里云控制台的“监控中心”里可以直接看字节命中率和请求命中率。静态资源为主的站点字节命中率长期应该在 95% 以上动态接口多的站点请求命中率可能只有 20% 到 40%这都不一定算异常关键在于“该缓存的缓存了没有不该缓存的有没有被强制缓存”。发现命中率突然下降时按这个顺序排查看最近有没有发布新版本静态资源文件名带不带 hash。不带 hash 的旧资源即使内容变了URL 没变CDN 还是会返回旧缓存这不是命中率低是命中错了。看控制台“实时日志”里回源状态码是否为大量 200。如果回源 200 多说明 CDN 穿透严重大概率是缓存 TTL 太短或 URL 参数太多。看源站带宽和 CDN 回源带宽。如果回源带宽突然飙升而 CDN 带宽没涨那就是穿透了反之则可能是源站出问题或者节点故障。检查是否有人恶意刷 URL。很多带随机参数的 URL 刷过来CDN 每个都不命中就会导致命中率暴跌。此时可以在“访问控制”里配置 URL 鉴权或单 IP 限频。4. HTTPS 证书免费证书、自动续期和上传流程4.1 阿里云免费 SSL 证书的申请、签发和 CDN 绑定阿里云每年可以申请一定数量的免费 SSL 证书单张证书有效期现在是 3 个月以前是一年签发后可以绑定到 CDN、SLB、OSS 等云产品上。很多人嫌 3 个月续期麻烦其实现在阿里云已经支持“自动续期”了证书到期前系统会自动申请新的免费证书并部署到 CDN。前提是你得保证域名 DNS 解析正常且证书申请时采用的“DNS 验证”方式权限还在。申请路径控制台搜索“数字证书管理服务” - 证书申请 - 选择“单域名证书” - 证书类型选“免费证书” - 填写域名和验证方式。如果域名在阿里云云解析 DNS验证会很快一般几分钟内签发。签发完成后在证书列表点击“部署”选择产品类型为 CDN系统会自动把证书推送到 CDN 域名配置里。这里有个细节证书部署到 CDN 后源站的 HTTPS 证书是独立的。也就是说CDN 边缘节点和客户端之间的 TLS 证书用你上传到 CDN 的这张CDN 回源到源站时用的是另一套源站自己的证书或按回源协议走 HTTP。所以你把免费证书部署到 CDN 后源站 Nginx 上的证书还是得自己维护二者不是同一个东西。4.2 Certbot 配合阿里云 CDN手动续期和自动化脚本有些用户不使用阿里云证书而是用 Let’s Encrypt 的证书用 Certbot 自动签发续期。这时 CDN 上需要手动更新证书。常见做法是在源站服务器上用 Certbot 申请或续期证书DNS 验证或 HTTP 验证。把证书文件和私钥内容复制出来。在阿里云 CDN 控制台“HTTPS 配置”里修改证书粘贴新的证书内容和私钥。点击“生效”等待节点下发。这个过程要是每个月做一次就很烦。可以写一个脚本续期后自动调用阿里云 OpenAPI 更新 CDN 域名证书。核心 API 是UpdateCdnDomain或SetCdnDomainSSLCertificate参数里带上CertName、CertContent、PrivateKey即可。你可以在服务器上用 Python 的aliyun-python-sdk-core和aliyun-python-sdk-cdn写个几十行的脚本加上 Cron 定时每月执行基本能做到无人值守。我提醒一点直接用 Certbot 的 HTTP-01 验证时如果域名已经接入了 CDNLet’s Encrypt 的验证请求可能会被 CDN 缓存或转发到边缘节点导致验证失败。因此建议申请证书时用 DNS-01 验证也就是加 TXT 记录。如果你用的是阿里云云解析 DNSCertbot 配合aliyun插件可以自动添加和删除 TXT 记录非常省事。4.3 HTTPS 回源和证书链不完整的问题还有一类常见故障CDN 上证书配置本身没问题但回源到源站时 TLS 握手失败表现为用户访问时偶发 502。这类问题在源站 Nginx 上证书链不完整时特别明显。Nginx 配置 SSL 证书时不仅要填fullchain.pem还要确保证书链里包含中间证书。如果你只填了域名证书部分客户端或 CDN 节点用 HTTPS 回源时会因为找不到中间证书而报错。排查方法也很简单在源站上用openssl s_client -connect 127.0.0.1:443 -servername 你的源站域名查看证书链输出里应该有一个完整的Certificate chain。如果只有一层说明中间证书没配全需要到证书服务商下载对应的中间证书合并进去。这个坑在我帮朋友排查时遇到过不止一次而且往往是在证书续期之后冒出来。5. 与 OSS、ECS、K8s 这些常见源站搭配时的特殊处理5.1 OSS 私有 Bucket CDN私有回源和鉴权配置如果你用 OSS 存放图片和安装包又想通过 CDN 加速访问建议把 Bucket 权限设置为“私有”然后让 CDN 回源时携带阿里云签名信息去 OSS 取文件。这样做的好处是文件不能直接被外部通过 OSS 域名访问只能通过 CDN 域名安全性和成本都可控。阿里云 CDN 控制台里开启“私有 Bucket 回源”后CDN 会自动携带签名回源不需要你在 OSS 上额外开放公共读权限。但要注意一个联动问题如果 OSS Bucket 开启了 CDN 加速并回源私有 Bucket同时你又用 OSS 的图片处理功能比如 ?x-oss-processimage/resize,w_100那 CDN 需要把参数透传给 OSS而 CDN 又可能开启“过滤参数”两者冲突时图片处理就会失效。我的做法是给图片处理单独走一个加速域名不在同一个域名上同时开启过滤参数和 OSS 处理参数。5.2 ECS 自建 Nginx 作为源站安全组、带宽和日志用 ECS 自建源站时核心的配置重点在安全组和日志上。阿里云 CDN 回源节点有固定的 IP 段虽然不会公开全部但一般情况下你不需要在安全组里只放行 CDN 回源 IP。因为你回源可能直接用 ECS 公网 IP安全组一旦限制过死CDN 回源反而失败。更合理的做法是在源站前面加一个 SLBSLB 后端挂 ECS然后 CDN 的源站地址填 SLB 域名。这样 ECS 的安全组只要放行 SLB 的私网 IP业务更安全CDN 回源也稳定。如果只是单台 ECS 测试环境那源站地址直接填 ECS 公网 IP 也没问题但一定要在 Nginx 里设置好server_name和日志格式否则出问题时你根本不知道哪些请求是 CDN 回源打过来的。我在 Nginx 日志里会单独加一个字段记录$http_x_forwarded_for这样 CDN 回源带过来的客户端真实 IP 就能记下来。阿里云 CDN 默认会在回源请求头里带上X-Forwarded-For源站只要开启set_real_ip_from信任 CDN 节点日志里的客户端 IP 就是真实的用户 IP而不是 CDN 节点 IP。这个设置对日志分析和封禁恶意 IP 非常重要。5.3 单节点 K8s 和容器镜像部署CDN 的前移能解决什么问题最近看到不少朋友在折腾单节点 K8s 上跑微服务环境遇到的一个共同问题是容器镜像拉取太慢。这里 CDN 能做的事情其实不是直接加速 Docker Registry而是可以换个思路把镜像仓库比如自建的 Harbor放到 CDN 后面或者把常用的基础镜像通过 OSS CDN 分发。我知道有些人不建议 CDN 加速 Docker Registry因为镜像分层文件普遍较大且不同客户端拉取时 Range 请求多CDN 的分片回源和 Range 支持要完整才行。阿里云 CDN 的“大文件下载”场景其实本身支持 Range 回源所以如果自建 Harbor 并发拉取量很大可以在 CDN 上配一个域名指向 Harbor同时启用 Range 回源拉取速度会有明显提升。不过要注意Harbor 的 API 路径里有动态 token 验证如果 CDN 把所有路径都缓存会导致拉取失败。建议只把/v2/下的 blob 路径加入缓存白名单其他路径直连回源。5.4 Maven 仓库的 CDN 加速给构建过程“减负”热搜词里有“Maven 配置阿里云仓库”这是另一个很有意思的场景。很多团队构建 Java 项目会配置阿里云 Maven 公共仓库但公共仓库的并发和速度在你的网络环境里未必理想。你可以这样玩搭建一个 Nexus 私服作为 Maven 镜像然后把 Nexus 的对外访问挂到 CDN 上或者直接在阿里云 CDN 上把maven.aliyun.com的某些 release 包缓存到自己的 CDN 域名。不过 Maven 仓库的数据时效性很特殊SNAPSHOT 版本随时可能更新绝对不能缓存RELEASE 版本发布后不可变适合长期缓存。所以真要给 Maven 仓库做 CDN 加速我建议只代理含有release路径的请求TTL 设成 30 天SNAPSHOT 路径全部不缓存走源站。这样构建过程中反复拉取的第三方 release 包直接命中 CDN速度会快非常多。6. 日常运维与故障排查命中率、状态码、CNAME 验证6.1 证明“域名走没走 CDN”CNAME 解析和全网探测有时候我们需要验证一个域名是不是真的经过 CDN或者确认自己配置的 CNAME 生效没有。最简单的办法是本地dig 域名看解析结果里是不是返回了阿里云 CDN 的 CNAME 域名比如xxx.w.cdngslb.com这类后缀。如果返回的是源站服务器 IP说明 CNAME 没有配置成功或者解析缓存还没更新。在阿里云控制台“域名管理”里每个加速域名都会显示一个 CNAME 地址你需要去 DNS 服务商处添加一条 CNAME 记录指向它。配置完成后用阿里云控制台自带的“CNAME 检测”功能可以快速确认。有些人会遇到“CDN 开启后源站 IP 仍然暴露”的情况这说明你在某些地方使用了源站 IP 直连比如邮箱服务、接口回调、爬虫直接请求等。可以通过在安全组里限制非 CDN 回源 IP 的访问或者在全站 HTTP 头里检查返回的Via头来判断。6.2 状态码语义和常见故障根因CDN 场景下常见的状态码就那么几个但含义和源站直接访问时有些不一样200节点有缓存或回源成功。301/302如果 CDN 开启了 HTTP 跳转 HTTPS会在边缘直接返回跳转不回源。403可能是 CDN 访问控制拦截也可能是源站返回 403 被透传。404通常是 CDN 回源后源站确实没有文件。要注意 CDN 默认对 404 不缓存如果有大量 404 请求每次都回源会给源站带来不小压力。我们一般会把 404 也缓存 60 秒但要确保源站的 404 不是“临时不存在”。502/504这两个是最常见的回源故障。502 一般是源站拒绝连接或 Nginx 挂了504 一般是回源超时。如果偶发可能是 CDN 节点到源站的网络抖动如果持续先检查源站负载和安全组。我记得有个特别容易忽略的场景CDN 回源到 SLBSLB 健康检查绑定了后端 ECS 的某一个端口但后端 ECS 上防火墙没放行这个端口SLB 健康检查失败后自动摘除后端结果 CDN 回源就持续 502。排查链路时常常只盯着 CDN 和 ECS忽略了中间的 SLB 健康检查配置。6.3 刷新预热、封禁 IP、限频和用量控制CDN 上线后日常运维离不开“刷新缓存”。阿里云 CDN 控制台支持 URL 刷新和目录刷新URL 刷新是精确到单个文件的目录刷新会把整个目录下所有文件都失效。缺点是刷新有配额限制目录刷新的配额和 URL 刷新的配额是分开的。我们团队在发布系统里会写一个脚本根据发布内容自动拼接 URL 列表调用阿里云 OpenAPI 的RefreshObjectCaches做批量刷新而不是每天上控制台点鼠标。如果你的 CDN 带宽费用经常超预算重点看两个配置一个是“用量封顶”在 CDN 控制台可以针对域名设置带宽上限超过后返回 429 或直接断流另一个是“单 IP 限频”可以对同一个客户端 IP 设置每秒最大请求数防止恶意刷流量。这两项在正式业务上建议至少开一个。我还习惯给回源带宽单独设一个告警因为回源带宽飙升往往比 CDN 带宽飙升更能反映源站被穿透的问题。6.4 日志分析和主动监控从“救火”变成“预防”阿里云 CDN 提供离线日志下载也支持日志投递到 SLS 日志服务。我建议有条件的话直接把日志接进 SLS然后做几个常用告警某个 URL 5 分钟内的 5xx 数量超过阈值、命中率低于某条线、带宽突增超过预估。把这些告警配置好后很多故障在用户反馈之前就能提前发现。离线日志里的字段非常关键Hit字段标识是否命中缓存Referer、User-Agent、X-Forwarded-For是排查盗刷和爬虫的主要依据。我见过一个案例某天 CDN 命中率突然从 95% 掉到 60%打开日志一看大量请求都带?v随机数的参数来源 IP 全是同一个 C 段。这是典型的 URL 参数刷缓存后来直接在访问控制里加了“URL 鉴权”并开启单 IP 限频流量马上就回归正常了。7. 几个容易犯错的边界场景和我的最终建议7.1 泛域名加速到底能不能开阿里云 CDN 支持泛域名如*.example.com加速但我不建议轻易使用。泛域名虽然省去每个子域名单独配置的麻烦但缓存配置、证书管理、访问控制都变成了一套规则套所有子域灵活性很差。比如api.example.com是动态接口static.example.com是静态图片如果挂在同一个泛域名下你没法针对不同子域名设置不同的缓存 TTL最终要么接口被缓存要么图片加速效果不明显。最稳妥的方案是精确域名配置静态资源一个域名动态 API 一个域名分享链接一个域名。多配置几条其实不费什么时间但后续排障和调优会方便得多。7.2 冷门但实用的功能Range 回源、分片回源和 Brotli 压缩很多大文件下载场景中如果用户请求整个文件的一部分比如视频拖动进度条而 CDN 节点没有缓存这部分分片CDN 默认会回源请求整个文件。这对源站带宽和文件 IO 都很不友好。启用了“Range 回源”后CDN 只会回源拉取客户端请求的那一段字节能大幅减少源站压力。阿里云 CDN 在“大文件下载”和“视音频点播”场景里一般默认开启其他场景可能需要手动确认。还有一个小功能经常被忽略Brotli 压缩。CDN 开启后对文本类资源JS、CSS、HTML会优先返回 Brotli 压缩格式比 Gzip 压缩率更高体积能减少 15% 到 25%。但它和“缓存 Key”没有冲突只要客户端请求头里带Accept-Encoding: brCDN 节点就能响应。这个建议在静态站点上无脑开对节省流量很有帮助。7.3 从整体架构看 CDN 的定位它不只是一层缓存最后说点我在实际运维中的体会。CDN 这套东西用得好的时候就像一个物流分拣中心把 90% 的静态包裹直接堆在离用户最近的前置仓只有 10% 的动态包裹才送回源站处理。但如果你没有规划好哪些东西进前置仓、哪些东西必须回源它就会变成一层“黑盒”让你在故障排查时多绕很多弯路。我踩过不少坑包括但不限于忘了给 OSS 私有 Bucket 开启 CDN 签名回源导致图片全部 403、证书自动续期没配好导致半夜 CDN 边缘节点证书过期、缓存规则写得太粗导致接口数据延迟 10 分钟。这些问题的共性都是“配置时少想了一步为什么”。所以我每次新建加速域名时都会先在文档里写清楚四个问题回源地址是什么、回源 HOST 是什么、哪些路径需要缓存、哪些参数需要保留。写完之后再动手配置出错的概率会小非常多。如果你现在刚准备接入阿里云 CDN我的建议是从一个静态资源子域名开始把缓存、证书、日志告警全部配通再逐渐扩大到其他业务如果你已经在用了但命中率一直不理想别急着加 TTL先开日志看看 URL 结构再到控制台调整过滤参数和缓存 Key很多问题都会迎刃而解。顺手把证书自动续期和用量封顶配好这层“前置仓”才能真正稳下来。
