Nginx的expires指令通过设置Cache-Control和Expires响应头间接影响CDN缓存行为；它不直接控制CDN，但为CDN提供标准缓存时效信号，主流CDN优先遵循max-age值。
Nginx 的
指令本身不直接控制 CDN 节点缓存行为，但它能通过设置响应头中的
和
字段，向 CDN（如 Cloudflare、Akamai、阿里云 CDN 等）传递明确的缓存时效指令，从而间接影响其边缘节点的缓存策略与更新节奏。
expires 指令如何影响 CDN 缓存决策
CDN 节点在收到源站响应时，会优先依据 HTTP 响应头中的缓存控制字段做判断。Nginx 的
指令会自动注入标准缓存头：
设置
→ 同时输出
和
设置
→ 输出
和
设置
→ 不添加任何缓存头，CDN 可能回退到自身默认策略（如 5 分钟或按文件类型匹配）
多数主流 CDN 严格遵循
，忽略
；少数老旧系统可能依赖
。因此，
是一种轻量、兼容性好的缓存信号方式。
配合 CDN 实现精准缓存更新的关键配置
仅靠
不足以应对动态内容或灰度发布场景，需结合其他机制协同工作：
区分资源类型设置不同过期时间
：静态资源（JS/CSS/图片）设长缓存（如 1 年），HTML 或 API 接口设短缓存（如 5 分钟或
）
利用版本化 URL 或指纹文件名
：让内容变更自然触发 CDN 缓存失效（如
），此时
安全且高效
对需主动刷新的内容，避免强依赖 expires
：CDN 通常提供 API 或控制台强制刷新功能，
仅用于“被动过期”，不能替代主动预热或 purge
注意 Nginx 的 if 判断限制
：不要在
块中使用
（语法允许但行为不可靠），改用
指令预定义缓存策略变量
常见误用与调试建议
实际部署中容易因配置细节导致 CDN 缓存行为偏离预期：
源站返回 304 却未带缓存头
：Nginx 默认对 304 响应不重写
，需显式配置
保证一致性
CDN 覆盖了源站缓存头
：部分 CDN 允许在控制台强制设置缓存规则，会覆盖 Nginx 的
，此时应关闭 CDN 的“强制缓存”选项，以源站为准
测试时忽略 CDN 缓存层级
：本地 curl 看到的是源站响应，不代表边缘节点行为；建议用
请求 CDN 域名，并检查
、
等头确认是否命中边缘缓存
一个典型静态资源缓存配置示例
以下配置适用于托管在 Nginx 上的前端项目，配合 CDN 使用：
}
提示 CDN 和浏览器该资源不会更改（配合指纹命名），可安全启用长缓存；而 HTML 的短缓存确保用户能较快获取新版本入口。
expiresCache-ControlExpiresexpiresexpires 1h;Cache-Control: max-age=3600Expires: [当前时间 + 1小时]expires epoch;Cache-Control: no-cacheExpires: Thu, 01 Jan 1970 00:00:01 GMTexpires off;Cache-Control: max-ageExpiresExpiresexpiresexpiresno-cacheapp.a1b2c3.jsexpires 1y;expiresifexpiresmapexpiresadd_header Cache-Control "max-age=3600";expirescurl -IX-CacheAgelocation ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?|ttf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
location / {
HTML 页面不长期缓存
expires 5m;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
immutable