电商大促前cdn回源预热核心是让源站缓存提前就位，需精准识别cdn回源流量、分层分级预热、严格限流控制，并建立量化验证闭环。

电商大促前对 CDN 回源做预热，核心目标是让源站缓存提前“就位”，避免开抢瞬间大量未缓存请求穿透到后端，引发雪崩。这不是简单地刷一遍 URL，而是结合业务节奏、缓存层级和回源特征的协同动作。

识别并隔离真实回源流量

预热的前提是准确区分 CDN 回源请求与普通用户直连——否则刷出来的可能是无效缓存，甚至干扰限流策略。必须在 http 块中定义可靠标识：

• 用 map 匹配主流 CDN 的 User-Agent（如 AlibabaCloud-CDN、Tencent-Cache、Cloudflare），设 $is_cdn_origin = 1
• 配合 set_real_ip_from 和 real_ip_header X-Forwarded-For，确保 $remote_addr 是 CDN 节点真实 IP，用于后续按 IP 预热或限流
• 禁用非 CDN 来源的预热请求：在预热专用 location 中加 deny all，再仅 allow 已知 CDN 的 IP 段

分阶段构建缓存层级

预热不是“全量刷”，要按资源热度和更新频率分级处理：

• 静态资源（图片/CSS/JS）：提前 48 小时开始，用脚本按 CDN 提供商推荐的回源 User-Agent 和 Header 发起 GET 请求；设置 Cache-Control: public, max-age=2592000，确保 CDN 和浏览器都长期缓存
• 商品详情页（HTML）：提前 6–12 小时启动，按商品 ID 列表轮询；缓存 key 必须含 $host + $request_uri + $args（但过滤掉 utm 类追踪参数），避免缓存碎片
• 动态片段（价格/库存）：不预热 HTML 全页，而是在 Nginx 层用 Lua 或 proxy_cache 单独缓存 /api/price/{id} 这类接口，TTL 设为 10–30 秒，由边缘层拼装

控制预热节奏，防止反向压垮源站

预热本身是流量，必须受控，否则等于自己发起一次压测：

• 用独立限流 zone，例如：limit_req_zone $remote_addr zone=warmup:10m rate=5r/s，仅对预热路径启用
• 预热请求加自定义 Header（如 X-Preload: true），在日志中单独标记，便于监控和快速熔断
• 配合 proxy_cache_lock on，防止同一资源被多个预热请求重复回源；搭配 proxy_cache_lock_timeout 5s 避免长锁阻塞
• 使用 proxy_cache_use_stale updating，确保预热更新期间旧缓存仍可服务，不出现空白期

验证与闭环反馈

预热效果不能只看日志，要建立可量化的验证机制：

• 在 server 块中开启缓存状态头：add_header X-Cache-Status $upstream_cache_status，通过采样回源响应确认 HIT 率是否达标
• 配置专用监控 location，返回当前缓存命中率、预热请求数、最近 5 分钟回源失败数等指标，供运维实时查看
• 大促前 30 分钟自动触发一次“缓存健康检查”：随机抽 100 个高热商品 URL，用 CDN 节点 IP 模拟回源请求，统计 200 响应占比低于 95% 时告警