CDN回源致源站CPU过高，主因是Nginx未隔离优化回源流量：需限制合法CDN IP回源并返回444、为回源请求跳过rewrite/鉴权等高开销模块、关闭其日志与gzip、启用HTTP/1.1连接复用、并基于回源IP限流限连。
CDN 回源时源站 CPU 过高，往往不是 CDN 本身的问题，而是 Nginx 配置未针对回源流量做合理隔离与优化。核心思路是：**区分回源请求与用户直连请求，对回源请求降级处理，避免重复解析、重写、鉴权等高开销操作。**
只允许指定 CDN IP 回源，拒绝非法回源
很多 CPU 升高源于恶意或误配置的“伪回源”——非 CDN 节点直接访问源站，绕过 CDN 缓存逻辑，导致大量动态请求打到 Nginx 后端。应严格限制回源来源。
- 在 Nginx 配置中使用 geo 或 map 模块预定义 CDN 回源网段（如阿里云、腾讯云、Cloudflare 官方公布的回源 IP 列表）
- 用 allow/deny 在 server 或 location 块中控制访问，例如：
location / {
deny all;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
# ... 其他 CDN 回源段
# 正常处理逻辑
} - 对拒绝请求统一返回 444（Nginx 特有关闭连接状态码），不记录日志、不构造响应，最小化 CPU 开销
为回源请求跳过耗 CPU 的模块逻辑
用户直连请求可能需要 WAF 规则、GeoIP 地域判断、复杂 rewrite、JWT 验证等；但 CDN 回源请求已由 CDN 完成前置校验，这些环节纯属冗余，必须绕过。
- 利用 $http_x_forwarded_for 或自定义 header（如 X-Forwarded-By-CDN: true）识别回源请求
- 用 map 创建变量标识是否为回源：
map $http_x_forwarded_for $is_cdn_origin {
default 0;
"~*^(103\.|199\.|141\.)" 1;
} - 在关键 location 中用 if ($is_cdn_origin) { ... } 或 try_files @cdn_fastpath 分流，将回源请求导向极简处理分支（如直接 proxy_pass，不加载 lua、不执行 rewrite_rule、不调用 auth_request）
关闭回源请求的日志与缓冲，减少内存/CPU 开销
高频回源场景下，每条 access_log 写入、gzip 压缩、response buffer 管理都会增加 CPU 负担，而回源日志价值远低于用户侧日志。
- 为回源 location 单独设置 access_log off;
- 禁用回源响应的 gzip：gzip off;（CDN 通常会自行压缩）
- 减小或禁用回源响应的 buffer：
proxy_buffering off;
proxy_buffer_size 4k;
proxy_buffers 8 4k;
避免 Nginx 在内存中缓存整个响应体再转发 - 启用 proxy_http_version 1.1 和 proxy_set_header Connection '' 复用后端连接，降低 TCP 建连开销
限制回源并发与频率，防突发冲击
CDN 预热、缓存失效或攻击可能导致短时海量回源请求，压垮源站。需在 Nginx 层做基础限流。
- 用 limit_req_zone 基于 CDN 回源 IP（而非用户 IP）定义限速区域：
limit_req_zone $binary_remote_addr zone=cdn_origin:10m rate=100r/s; - 在回源 location 中应用：
limit_req zone=cdn_origin burst=200 nodelay;
注意：burst 应略高于峰值预期，nodelay 避免排队延迟影响 CDN 回源时效 - 配合 limit_conn 控制单个 CDN 节点最大连接数，防止连接耗尽
