CDN控制台怎么看流量和网络日志：巡检顺序与异常排查动线

控制台里的数据其实分成两层，先分清这两层，排查就不会绕路：

监控看板（聚合指标）：带宽、流量、请求数、命中率、状态码占比。它回答的是“什么时候涨的、涨了多少、涨在哪一类响应上”。
网络日志（原始明细）：每一条请求的客户端IP、URI、状态码、Referer、UA、耗时。它回答的是“是谁在请求、请求了什么、卡在哪一步”。

顺序几乎不会变：先在看板上把异常时间段和异常维度圈出来，再带着这两个条件去日志里过滤。反过来先翻日志，几十万行里找不到重点。

一、三分钟看板巡检：按这个顺序看五个数

控制台一般会有两套监控视图。实时监控是1分钟或5分钟粒度的高频采样，用来看当下正在发生的波动；资源监控/用量统计跨度更长（常见30~90天），用来看趋势和月度对账。正在出问题时看前者，做容量和费用判断时看后者。

按这个顺序扫一遍：

带宽峰值（Mbps/Gbps）：先确认尖峰出现在哪个5分钟点，记下时间。这个时间点就是后面日志检索的过滤条件。
总下行流量：流量涨得多但带宽曲线平缓，说明是持续拉取；带宽有尖刺但总量不大，更像瞬时并发。
请求数 / QPS：把它和流量对照着看，这一步能直接分流出两类问题（见下节）。
流量命中率：常见算法是（总下行流量 − 回源流量）/ 总下行流量。同时把回源带宽单独调出来对照。
HTTP状态码分布：看2xx/3xx占比是否被4xx（403、404）或5xx（502、504）挤掉。

流量和请求数的比值，先分出两类异常

流量暴涨、请求数基本不动 → 单次请求体积变大了。多半是大文件（安装包、视频、图片原图）被盗链或被集中下载。
请求数暴涨、单请求流量很小 → 高频小请求。CC攻击、爬虫集群、接口被刷都落在这一类。
两者同涨，同时命中率骤降、回源带宽跟着暴涨 → 请求没能在边缘节点被挡住，正在穿透到源站。典型成因是携带随机参数的缓存穿透（Cache Busting），也可能是缓存规则刚改坏了。这种情况最需要立刻处理，因为压力全部压在源站上。

根据流量与请求数关系区分三类CDN异常的判断分支图

二、网络日志怎么取：实时检索和离线下载

控制台里拿日志通常是两条路，用途不一样：

实时日志面板 / 日志检索：延迟在秒级到分钟级，支持按时间、域名、状态码、URI关键字过滤。正在处置故障时用它，边看边缩小范围。
离线访问日志下载：按小时或按天归档成标准日志文件（常见是压缩过的 access.log），可以下载到本地。适合做事后复盘、跨几天的批量统计、以及月度流量对账。

离线日志通常有延迟（不同平台从十几分钟到几小时不等），不要指望用它处理正在发生的攻击。

三、必须核对的几个日志字段

不管哪家平台，能支撑判断的就是这几列：

字段（常见命名）	用来回答什么
client_ip / remote_addr	谁在请求。按IP聚合出Top列表，判断是CC、爬虫集群还是单机脚本
request_uri / uri	请求了什么。按URL聚合，定位被盗刷的大文件或被打爆的某个接口
http_code / status	是谁返回的错。区分CDN侧拦截还是源站报错
referer / refer_domain	来源页面。排查是否有未授权站点盗链引流
user_agent	客户端标识。识别扫描器、批量工具、伪造的浏览器UA
回源耗时（upstream_response_time 等）	慢在哪一段。源站处理慢还是网络抖动
缓存状态（HIT/MISS）	请求有没有回源。配合命中率异常一起看

字段名和字段顺序各平台不一致，客户端IP在有的平台叫 client_ip、有的叫 remote_addr，部分平台的日志格式还会把耗时放在不同列位。下载日志前先在控制台找到该域名的日志字段说明/字段字典，确认每一列是什么，再写统计命令，否则 awk 取错列会得出完全反过来的结论。

拿到离线日志后，最常用的两条统计（列号按实际日志格式替换）：

# Top 20 高频客户端IP
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

# Top 20 被请求最多的URI
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20

# 只看某个时间段的非2xx请求
grep "14:2[0-9]:" access.log | awk '$9 !~ /^2/ {print $9, $7}' | sort | uniq -c | sort -rn

判断一个IP是不是恶意，别只看请求次数。正常用户走CDN也会有较高频次（页面里的静态资源）。更可靠的组合是：单IP请求数高 + 集中在同一个动态URI + UA单一或异常 + 几乎没有静态资源请求。

四、四类常见异常的排查动线

1. 某个文件流量被刷爆

看板确认流量涨、请求数平 → 日志里按 request_uri 聚合，找出流量占比最大的几个URL → 对这几个URL按 referer 聚合。如果大量请求的 Referer 指向不属于你的域名，就是盗链；如果 Referer 为空且 client_ip 分散，更像是直链被人分发出去了。处置方向是开防盗链（Referer白名单）或对该路径加签名鉴权。

2. 命中率骤降、回源带宽暴涨

先看MISS请求的URI长什么样。如果同一个路径后面挂着不断变化的随机参数（?v=193847、?t=xxx），说明缓存键被参数打散了，每个请求都在回源。短期处置是配置忽略指定参数/参数白名单让它们共用一份缓存，同时对来源IP做频率限制。如果MISS的URI本来就是动态接口，那就是纯粹的请求量上来了，走限流和人机校验的路子。

接口类被高频刷取的处理顺序，可以参考大模型API接口被盗刷怎么限流里的分层阈值思路。

3. 403陡增

403不是一个原因，先在日志里区分是谁返回的：

检查请求的 Referer 和 User-Agent，对照你自己配的防盗链规则、UA黑白名单、IP黑名单——被这些规则挡掉的请求，特征通常很整齐（同一段UA、同一批IP）。
看 CDN 的错误响应头/拦截标记（不同平台标记不同，例如 X-Tengine-Error 这类字段，或WAF的拦截规则ID字段）。有拦截标记的是边缘挡的，没有的往往是源站自己返回的403。
如果403打在正常业务路径上，尤其是回调、上传、后台接口，优先怀疑规则误伤。

误伤了支付回调这类不能重试的路径，处理顺序见WAF把支付回调拦了怎么加白名单。

4. 502 / 504

先筛出状态码为502/504且缓存状态为MISS的记录，再看这批记录的回源响应耗时：

耗时接近超时阈值且逐渐变长 → 源站处理不过来（数据库、连接池、CPU），先扩源站或降级。
耗时极短就报错 → 更像连不上，检查源站是否宕了、端口是否被封、源站防火墙有没有把CDN回源IP挡掉。
只有部分节点/部分地区出现 → 偏向线路问题，把同一时间段按节点或地区维度拆开看。

5xx和攻击经常同时出现：源站被打到过载，先返回504，再彻底没有响应。这时别停在日志上，直接按网站被DDoS攻击了怎么快速恢复访问的顺序止血。

五、别只在出事时才打开控制台

两件事值得提前配好：

一是告警和推送。 把带宽峰值、5xx占比、命中率设成阈值告警，并推到你实际会看的地方。RockCloud 的控制台提供日志面板和 Telegram 数据推送，异常曲线不用靠人工盯着刷新；具体的面板能力和节点分布可以在CDN与节点页面确认。

二是搞清楚看板上的哪个数字对应账单。 按流量计费看的是总下行流量，按峰值计费看的是带宽采样点——同一段曲线，两种计费口径算出来的钱可能差很多。RockCloud 采用固定峰值计费、不限流量，所以巡检时真正要盯的是带宽峰值有没有顶到套餐上限，而不是月流量总量。三种峰值算法（5分钟采样点、月95、固定峰值）的差别，展开在高防CDN按峰值计费怎么算。

最后一句提醒：看板上的一次尖峰，不等于一次攻击。促销推送、APP版本更新、爬虫抓取、监控探针误配都会造成同样的曲线形状。先去日志里确认请求来源和请求内容，再决定是扩容、加缓存规则，还是上拦截。