CDN 加速：接入、缓存与回源

接入前，先确认源站与 HTTPS

1. 源站可以正常响应。确认回源地址、协议和端口正确，源站防火墙允许必要的访问；回源地址不要再次指向同一 CDN 入口，以免形成循环。
2. 域名解析指向正确入口。按项目要求配置 DNS，清理冲突记录，并核对实际解析结果。
3. 分别检查两段 HTTPS。浏览器到边缘节点、边缘节点到源站是不同连接。使用 HTTPS 回源时，源站的证书与请求主机名也需要匹配。

先区分公共资源与个性化响应

是否可缓存取决于实际响应，不能只看文件后缀。带查询参数的请求也可能返回不同内容，需要确认缓存规则能正确区分。

把 Cache-Control 与 Cookie 边界写清楚

先使用默认配置验证公共静态资源，再按需要调整 TTL、路径排除、Cookie 处理和 Cache-Control 策略。更新越频繁的内容，越需要考虑有效期与刷新方式。

源站的 Cache-Control: private 表示响应面向单个用户；no-store 表示不应存储。不要用宽泛的强制缓存规则覆盖这些业务意图。携带登录 Cookie、Authorization 或返回 Set-Cookie 的响应，应先核实其用途与排除规则，再决定能否缓存。

用真实请求验证缓存是否生效

1. 选一个允许缓存的公共文件，连续请求同一个完整 URL，检查响应状态、响应头与内容。
2. 结合实际返回的缓存标识、Age 等响应头及源站访问日志，判断后续请求是否减少回源；不同节点可能各自经历首次回源。
3. 分别测试未登录和登录状态，确认账户与订单内容不被共享，再检查资源更新和刷新后的结果。

可将下列示例地址替换为自己的文件，以 GET 请求查看响应头：

curl -sS -D - -o /dev/null https://cdn.example.com/assets/app.css

单次加载变快不能单独证明命中缓存；浏览器本地缓存也会影响观测。

按故障出现的位置排查

• 域名打不开：先查 DNS 是否生效，再查入口与源站连通性。
• 证书错误或跳转循环：检查证书主机名、回源协议及源站跳转规则。
• 持续回源：核对路径排除、有效期、Cookie 与源站缓存响应头。
• 内容没有更新：区分浏览器与边缘缓存，再按 URL 或路径刷新，必要时更换资源版本。