CDN预热需Nginx配合四点核心配置：一是URL稳定可预测，用正则精确匹配带哈希的资源路径；二是返回强缓存头（Cache-Control public,immutable,max-age=31536000）及跨域头；三是开放预热请求访问权限，避免限速或防盗链误拦；四是支撑批量预热，确保try_files准确响应且root路径与构建输出一致。
要让静态资源在用户访问前就“提前准备好”并缓存在 CDN 边缘节点，关键不是等请求触发回源，而是主动把资源推过去——这就是 CDN 预处理（常称“预热”）。Nginx 本身不直接发起预热请求，但它必须配合：提供可被预热的稳定 URL、返回可信缓存头、支持跨域预热调用，并为后续大规模预热打下结构基础。
以下四点是真正落地的核心配置项：
确保资源 URL 稳定且可预测
CDN 预热依赖完整、确定的 URL（如 https://static.example.com/js/vendor.a1b2c3.js），所以前端构建必须输出带内容哈希的文件名。Nginx 需能准确匹配这类路径：
- 在 location 块中用正则精确捕获 vendor、chunk、asset 等命名模式，例如：
location ~ ^/js/(vendor|main|runtime).[a-f0-9]{8,}.js$ { ... } - 避免使用通配后缀（如
\.js$）匹配所有 JS，否则会把未哈希的调试文件也纳入预热范围，造成无效缓存或冲突。
返回强缓存响应头，让 CDN 愿意长期存
预热只有在 CDN 认为“值得缓存”时才有效。Nginx 必须对目标资源显式设置：
- add_header Cache-Control "public, immutable, max-age=31536000";
- 同时配 expires 1y;（作为浏览器缓存兜底）
- 加 add_header Access-Control-Allow-Origin "*";（允许预热脚本跨域发起 GET 请求）
注意：不要用no-cache或private，这些会直接拒绝 CDN 缓存。
开放预热请求的可访问性与安全性
CDN 预热本质是外部 HTTP GET 请求，需确保：
- Nginx 不拦截或限速这类请求（避免
limit_req或deny all误伤） - 若配置了 referer 防盗链，需临时放行空 referer 或预热来源 IP（如阿里云 CDN 的预热 IP 段）
- 可加简易日志标记便于排查：
log_format cache_preheat '$remote_addr - $request_time "$request" $status $upstream_cache_status';
为批量预热提供结构支撑
单个文件手动预热效率低。建议将 Nginx 配置与 CI/CD 流水线打通：
- 构建完成后，提取 dist 目录下所有带哈希的 JS/CSS/字体路径（如
find build -regex ".*\.\(js\|css\|woff2\)$" -type f） - 将其拼成完整 CDN URL 列表（
https://static.example.com/xxx.js） - 调用 CDN 提供的预热 API（如阿里云
PushObjectCache）批量提交
Nginx 此时只需保证每个 URL 都能 200 响应——这就要求try_files $uri =404;准确生效，且 root 路径与构建输出一致。
不复杂但容易忽略
