nginx 本身不支持自动预取，预热本质是服务端主动发起请求触发 proxy_cache 或 fastcgi_cache 首次填充；需满足启用缓存、响应头允许缓存等前提，优先预热高访问低更新的首页、关键接口及版本化静态资源，常用 curl 脚本或 internal location 实现可控预热。
明确适用场景与前提条件
预热只对走缓存逻辑的请求有效，需满足：
• 启用了 proxy_cache（反向代理场景）或 fastcgi_cache（PHP-FPM 场景）；
• 对应 location 中配置了 proxy_cache_valid、proxy_cache_key 等关键指令；
• 后端响应头允许缓存（如 Cache-Control: public, max-age=3600），且未携带 Set-Cookie 或 Cache-Control: private 等禁止缓存字段；
• 静态文件直出（root/alias）默认不进 proxy_cache，除非额外封装为代理请求。
聚焦头部资源，避免全站轮询
预热不是越多越好，而是要精准覆盖高价值路径。优先选择：
• 访问量大、更新频率低的页面（如首页 /、产品列表 /products、帮助中心主文档）；
• 首屏强依赖的关键接口（如 /api/config、/api/banner）；
• 版本化静态资源（如 /static/js/app.v2.4.js、/static/css/main.css）；
• 排除含用户身份、实时参数、上传路径（如 /user/、/search?q=xxx、/upload/）等动态敏感内容。
用脚本模拟请求，实现可控预热
最常用、最可靠的方式是写 Bash 脚本配合 curl 主动触发：
• 使用 -I 发起 HEAD 请求，轻量高效，不传输响应体；
• 加 -H "User-Agent: nginx-warmup" 方便日志识别和规则隔离；
• 用 -s -o /dev/null -w "%{http_code}\n" 静默执行并检查状态码；
• 控制并发数（如 parallel -j 5），防止压垮后端；
• 加简单重试逻辑（失败后延迟 1 秒再试一次）；
• 示例命令：curl -I -s -o /dev/null -H "User-Agent: nginx-warmup" https://example.com/home
通过 internal location 实现受控预热入口
更规范的做法是在 Nginx 配置中定义专用预热入口：
• 新增 location，用 internal; 或 allow 127.0.0.1; 限制仅本机调用；
• 设置独立缓存区（如 keys_zone=precache:256m），避免干扰线上缓存；
• 在该 location 中配置 proxy_pass 和完整缓存指令（proxy_cache_valid、proxy_cache_use_stale 等）；
• 配合定时任务（如 crontab 每日凌晨 3 点执行）或发布流程自动调用；
• 注意：URL 参数需通过 $arg_url 提取，并用 rewrite 或 map 拼接到后端地址，确保真实路径被缓存。
