Nginx proxy_cache 不支持自动预热，需用脚本主动请求热点URL（如首页、商品页等）触发缓存；脚本应排除带用户参数的URL，配合Nginx缓存配置及部署流程执行，并通过响应头或缓存目录验证效果。
Nginx 的 proxy_cache 本身不支持自动预热，需配合外部脚本主动发起请求，把热点数据“提前刷”进缓存。核心思路是：在服务上线前或低峰期，用脚本批量请求关键 URL，触发 Nginx 缓存存储。
明确哪些 URL 属于“热点”
预热不是全站抓取，而是聚焦高访问、低更新、高生成成本的资源。常见类型包括：
- 首页、频道页、商品列表页（如
/、/category/123） - 爆款商品详情页（如
/product/8888，可从运营后台或日志提取 Top 100） - 静态化 HTML 页面（后缀为
.html或无后缀但由后端渲染） - 注意排除带用户态参数的 URL（如
?uid=xxx、sessionid），避免污染缓存
编写轻量预热脚本（推荐 curl + bash）
以下是一个可直接运行的示例脚本（保存为 cache_warmup.sh）：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
#!/bin/bash
# 配置目标域名和超时
DOMAIN="https://example.com"
TIMEOUT=5
<h1>热点 URL 列表（每行一个，支持路径或完整 URL）</h1><p>URLS=(
"/"
"/category/1"
"/product/1001"
"/product/1002"
"/about"
)</p><p>echo "开始预热 ${#URLS[@]} 个 URL..."
for url in "${URLS[@]}"; do
full_url="${DOMAIN}${url}"
echo -n "请求 $full_url ... "
if curl -s -o /dev/null -w "%{http_code}\n" --max-time $TIMEOUT "$full_url" | grep -q "^200$"; then
echo "✅ 缓存已加载"
else
echo "❌ 请求失败"
fi</p><h1>小间隔防压垮上游（可选）</h1><p>sleep 0.1
done
使用前需确保：
– 脚本有执行权限（chmod +x cache_warmup.sh）
– Nginx 已配置好 proxy_cache 且对应 location 支持缓存（含 proxy_cache_valid）
– 后端服务正常响应，且返回头中不含 Cache-Control: no-store 或 Set-Cookie（会阻止缓存）
集成到部署流程中
预热应在新版本发布后、切流前执行，推荐方式：
- 加入 CI/CD 流程末尾（如 Jenkins Pipeline、GitHub Actions），部署完 Nginx 配置后自动运行
- 搭配 systemd timer 或 crontab 定期执行（适用于内容更新较慢的页面，如每周一凌晨刷新栏目页）
- 通过 Ansible 或 SaltStack 在多台 Nginx 服务器上并行触发，加快全集群预热
验证缓存是否生效
预热后不要只看状态码，要确认 Nginx 确实写入了缓存文件：
- 检查缓存目录（如
/var/cache/nginx/proxy_cache/）是否有新增文件 - 用
curl -I查看响应头：
✅ 有X-Proxy-Cache: HIT或HIT from example.com（需在 Nginx 中配置add_header X-Proxy-Cache $upstream_cache_status;）
✅Age头大于 0 表示命中缓存 - 对比首次请求（MISS）和二次请求（HIT）的
Server-Timing或响应时间差异
不复杂但容易忽略：预热脚本只是“触发器”，真正起作用的是 Nginx 的缓存策略是否匹配业务——比如动态接口不能缓存却写了 proxy_cache_valid 200 10m，预热也没意义。先理清哪些该缓、缓多久、怎么区分 key，再写脚本才有效。
