Nginx proxy_cache怎么配置缓存热点数据预热脚本-Nginx-PHP中文网

nginx proxy_cache 不支持自动预热，需用脚本主动请求热点url（如首页、商品页等）触发缓存；脚本应排除带用户参数的url，配合nginx缓存配置及部署流程执行，并通过响应头或缓存目录验证效果。

nginx proxy_cache怎么配置缓存热点数据预热脚本

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
</p>

使用前需确保：
– 脚本有执行权限（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 或响应时间差异