源站带宽成本是许多网站运维支出的大头，而CDN本应减轻源站压力，却经常出现回源流量失控的情况：缓存命中率低、CDN节点频繁回源、大文件被反复拉取，最终源站出口带宽被打满，费用直线上升。要解决这个问题，第一步不是急着加限速规则，而是先把Nginx访问日志分析清楚，搞清楚回源流量到底来自哪里、请求的是什么内容、占了多少带宽，再针对性地制定控制策略。
一、配置Nginx日志，记录回源流量的关键信息
默认的Nginx日志格式对回源分析来说信息量不够，我们需要自定义log_format，把CDN节点的真实IP、请求字节数、缓存状态等字段记录下来。CDN回源时通常会携带X-Forwarded-For头，第一段是用户真实IP，最后一段是CDN节点的边缘IP，通过日志区分两者，才能算清每个CDN节点的回源带宽。
下面是一个适合回源分析的日志格式配置，建议放在http块中：
log_format cdn_analysis '$time_iso8601 '
'remote_addr=$remote_addr '
'xff=$http_x_forwarded_for '
'request="$request" '
'status=$status '
'body_bytes_sent=$body_bytes_sent '
'request_time=$request_time '
'upstream_cache_status=$upstream_cache_status '
'referer=$http_referer '
'ua="$http_user_agent"';
server {
listen 80;
server_name origin.ipipp.com;
access_log /var/log/nginx/origin_access.log cdn_analysis;
# 反向代理缓存配置，配合日志中的upstream_cache_status分析命中率
proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=origin_cache:100m max_size=10g inactive=1d;
proxy_cache origin_cache;
location / {
proxy_pass http://backend;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
add_header X-Cache-Status $upstream_cache_status;
}
}
这里有几个字段值得重点关注：$body_bytes_sent是实际发送给CDN节点的字节数，是计算回源带宽的核心数据；$upstream_cache_status的值包括HIT、MISS、EXPIRED、BYPASS等，如果MISS占比过高，说明源站自身的缓存层没有发挥作用，每次回源都穿透到后端；$http_x_forwarded_for则用于区分回源请求来自哪个CDN节点。
另外要注意，如果CDN回源走的是HTTPS，日志里还要确认SNI和Host头是否正确传递，否则可能出现CDN回源请求全部落到默认server块的情况，导致统计偏差。可以在日志中临时加上$host字段做校验。
二、用日志分析工具统计回源带宽分布
日志记录下来只是第一步，关键是从中提取出有价值的信息。轻量级场景直接用awk就能完成大部分统计工作，比如统计过去一小时各CDN节点的回源带宽：
# 统计最近1小时各CDN边缘节点的回源流量（单位MB）
awk -v since="$(date -d '1 hour ago' '+%Y-%m-%dT%H')" '
$1 >= since {
# 提取xff最后一段作为CDN节点IP
n=split($3, arr, ",")
node=arr[n]
gsub(/cdn_node=/, "", node)
gsub(/body_bytes_sent=/, "", $6)
bytes[node]+=$6
}
END {
for (k in bytes) printf "%s\t%.2f MB\n", k, bytes[k]/1024/1024
}' /var/log/nginx/origin_access.log | sort -k2 -nr
如果需要更直观的实时分析，GoAccess是不错的选择，它支持终端实时输出，也支持生成HTML报表。针对自定义日志格式，需要写一份对应的解析配置：
# goaccess.conf 关键配置
time-format %Y-%m-%dT%H:%M:%S%z
date-format %Y-%m-%dT
log-format %d %H:%M:%S%z remote_addr=%h xff=%~[^ ]* request="%r" status=%s body_bytes_sent=%b request_time=%T upstream_cache_status=%~[^ ]* referer=%~[^ ]* ua="%u"
# 启动实时终端监控
goaccess /var/log/nginx/origin_access.log --config-file=/etc/goaccess/goaccess.conf \
--geoip-database=/usr/share/GeoIP/GeoLite2-City.mmdb
通过分析，通常会发现回源带宽集中在少数几个维度上：一是特定的大文件，比如安装包、视频切片，这类文件单个请求就能消耗几十MB；二是特定CDN节点或特定区域，某些节点缓存淘汰策略激进，回源频率明显高于其他节点；三是低缓存命中的动态接口被CDN错误配置了缓存规则。找到这些集中点，后续的控制策略就有了明确靶子。
建议建立一个每日定时任务，把各CDN节点的回源带宽、TOP100回源URL、缓存命中率统计结果输出到报表，持续观察趋势。带宽问题往往是渐进恶化的，有趋势数据才能在打满之前预警。
三、基于分析结果实施带宽控制策略
明确了流量特征之后，就可以分层实施控制。第一层是限速与连接数控制，Nginx原生提供的limit_req和limit_conn模块足以应对大多数场景：
http {
# 按CDN节点IP限制回源请求速率，每秒10个请求，突发允许20个排队
limit_req_zone $binary_remote_addr zone=cdn_req:20m rate=10r/s;
# 按CDN节点IP限制并发连接数
limit_conn_zone $binary_remote_addr zone=cdn_conn:20m;
server {
listen 80;
server_name origin.ipipp.com;
# 大文件单独限速，控制在每秒50MB以内
location /download/ {
limit_rate_after 10m; # 前10MB不限速，保证小文件体验
limit_rate 50m; # 之后限速50MB/s
limit_conn cdn_conn 20;
limit_req zone=cdn_req burst=20 nodelay;
proxy_pass http://backend;
}
location / {
limit_conn cdn_conn 50;
limit_req zone=cdn_req burst=50 nodelay;
proxy_pass http://backend;
}
}
}
limit_rate针对单个连接限速，配合limit_rate_after可以做到小文件不限速、大文件限速的精细控制，这对回源大文件特别有效。limit_conn限制单个CDN节点的并发连接数，防止某个节点突发回源把源站连接池占满。要注意限速是把双刃剑，设置过严会导致CDN节点回源超时，进而触发CDN侧重试，反而放大请求量，因此阈值应基于日志统计的P99峰值来设定，并逐步收紧。
第二层是减少回源次数，这是更根本的手段。通过日志发现的低命中率URL，要逐类处理：静态资源在响应头中明确缓存策略，例如Cache-Control: public, max-age=604800；版本化的大文件资源启用内容哈希，文件名带指纹实现永久缓存；对于突发热度内容，可以在CDN控制台开启预热的API，让CDN主动拉取而不是等用户请求触发回源。此外，在源站Nginx上开启proxy_cache_lock on;，能确保同一个URL在缓存失效时只有一个请求穿透到后端，其余回源请求等待缓存填充，这一项配置对抑制回源风暴立竿见影。
第三层是服务级别的兜底保护。可以结合日志数据编写监控脚本，当检测到回源带宽持续超过设定阈值时，自动调整限速参数或临时返回降级内容。也可以利用Nginx的map指令根据$upstream_cache_status和请求特征做灰度控制，比如对EXPIRED状态的请求降低优先级处理。整个链路的核心思路是：日志提供数据，数据指导策略，策略的效果再通过日志验证，形成闭环。
总结一下，CDN回源带宽控制不是单点配置能解决的问题，Nginx日志在其中扮演的角色是数据基础：先通过合理的log_format记录足够的细节，再用awk或GoAccess定位带宽消耗的集中点，最后用limit_rate、limit_conn控制瞬时峰值，用缓存策略和proxy_cache_lock降低回源总量。做完这套闭环，源站带宽通常会下降30%到60%，而且控制粒度完全掌握在自己手里，不必依赖CDN厂商的定制方案。