nginx无内置缓存预热机制，需通过外部脚本模拟请求触发proxy_cache或fastcgi_cache生成；须先确认缓存类型与配置，再用带重试、并发控制及标识头的curl脚本预热url，并验证hit状态与缓存文件落地。
Nginx 本身不内置缓存预热机制，所谓“冷启动预热”，本质是模拟真实请求，主动触发 Nginx 的 proxy_cache 或 fastcgi_cache 缓存生成过程，避免用户首次访问时经历慢响应。关键不在 Nginx 配置本身，而在于外部驱动——用脚本发起精准、可控、可重复的请求。
明确缓存类型与命中路径
预热前必须确认你用的是哪类缓存：
-
反向代理缓存（proxy_cache）：适用于静态资源由后端（如 Node.js、Python 应用）动态生成，Nginx 作为前置缓存层；需检查
proxy_cache_path、proxy_cache、proxy_cache_valid等指令是否启用，且响应头中包含允许缓存的Cache-Control或Expires。 -
FastCGI 缓存（fastcgi_cache）：常见于 PHP-FPM 场景；需确认
fastcgi_cache_path和fastcgi_cache已配置，并在location ~ \.php$块中启用。 -
注意：纯静态文件（如
location ~* \.(js|css|png)$直接root或alias）默认不走 cache 指令，除非你额外配置了add_header X-Cache-Status $upstream_cache_status并结合expires+open_file_cache—— 这属于系统级文件句柄缓存，不是 proxy/fastcgi 类型的“热点入缓存”范畴。
编写轻量预热脚本（Bash 示例）
核心思路：读取热点 URL 列表，逐条用 curl -s -o /dev/null -w "%{http_code}\n" -H "Host: example.com" 发起请求，忽略响应体、只关注状态码和缓存效果。
- 准备
hot_urls.txt，每行一个完整 URL（如https://cdn.example.com/assets/app.abc123.js），支持带 query 参数（如需预热不同尺寸图片）。 - 脚本中加入简单重试逻辑（如失败则再试 1 次），避免因瞬时网络抖动误判。
- 添加并发控制（例如用
parallel -j 5或xargs -P 5），防止压垮后端或触发限流；5～10 并发通常足够，具体看上游承载能力。 - 建议在请求头中加
-H "User-Agent: nginx-warmup"，便于在后端或 Nginx access_log 中识别预热流量，必要时可配合map指令做日志隔离或拒绝写入。
验证缓存是否真正生效
不能只看脚本返回 200，要确认缓存已写入并可命中：
- 检查 Nginx 缓存目录（
proxy_cache_path指定路径）下是否有对应 hash 文件生成，例如：/var/cache/nginx/proxy_temp/ab/cdef0123456789...。 - 用
curl -I查看响应头：X-Proxy-Cache: HIT（或X-FastCGI-Cache: HIT）表示命中；首次请求应为MISS，二次请求变HIT即成功。 - 若始终是
BYPASS或EXPIRED，需排查：请求方法是否被限制（如只缓存 GET/HEAD）、响应头是否含Set-Cookie、Vary头是否导致缓存键过细、或proxy_cache_bypass规则意外生效。
集成到部署流程中
预热不是一次性操作，应嵌入 CI/CD 或发布后钩子中：
- 在新版本 Nginx 配置重载（
nginx -s reload）之后、切流之前执行预热脚本。 - 若使用蓝绿部署，可在新实例启动后、加入负载均衡前完成预热，确保上线即“热”。
- 对长期运行的服务，可每日凌晨低峰期定时执行一次轻量预热（仅核心 URL），对抗缓存自然过期；配合
proxy_cache_use_stale updating可进一步降低抖动影响。
