nginx流量占比分析需按业务维度切片聚合，重点验证数据是否反映真实分发逻辑与用户行为：①用$scheme统计https占比；②通过$upstream_addr映射反推后端节点实际流量 vs 配置权重；③referer+user-agent+协议多维交叉分析来源；④小时级趋势比总量更具决策价值。
分析 Nginx 日志中的流量占比模型，核心是把原始日志按业务维度切片、聚合、对比，而不是只看总数。重点不在“有没有数据”，而在于“数据是否能反映真实分发逻辑和用户行为分布”。
区分协议类型：HTTP 与 HTTPS 流量占比
协议占比直接体现安全策略落地效果和客户端兼容性。Nginx 日志中 $scheme 变量（如 http 或 https）是最准确的判断依据。
- 确认
$scheme在日志格式中的列位置（常见为第12列，但需用head -1 access.log实际验证） - 统计 HTTPS 请求占比（保留两位小数）：
awk '$12=="https"{h++} {t++} END{printf "%.2f%%\n", h/t*100}' /var/log/nginx/access.log - 若未启用
$scheme，可通过$server_port（443 → HTTPS）或响应头$http_x_forwarded_proto间接推断，但可靠性较低
拆解后端节点：真实流量分配 vs 配置权重
配置的 weight 是理论值，真实占比受健康检查、连接数（least_conn）、会话保持（ip_hash）等影响，必须从日志反推。
- 通过
map $upstream_addr $backend_id映射后端地址到标识符（如"10.0.1.10:8080" "node-a"） - 配合动态日志路径：
access_log /var/log/nginx/backend/$backend_id-access.log node_log; - 按小时统计各节点请求数：
awk '{print $13}' /var/log/nginx/backend/node-a-access.log | sort | uniq -c（$13为$backend_id字段位置） - 对比实际占比与配置权重比例（如 weight=3:2:5 → 理论应为 30%:20%:50%），偏差超 ±5% 就需排查节点健康状态或负载策略
识别访问来源：协议 + Referer + User-Agent 多维交叉
单一维度易失真，比如某 Referer 流量突增，需同步看是 HTTP 还是 HTTPS 请求、来自哪些浏览器、是否集中于特定 IP 段。
- 提取 Referer 并关联协议：
awk -F'"' '$12=="https" {print $4}' access.log | sort | uniq -c | sort -nr - 统计主流客户端协议分布：
awk '$12=="https" && $16 ~ /Chrome/ {c++} $12=="http" && $16 ~ /Chrome/ {h++} END {print "HTTPS-Chrome:", c, "HTTP-Chrome:", h}' access.log（假设$16为 User-Agent） - 避免仅依赖
$http_referer，空 Referer（直接访问）和伪造 Referer 需单独归类
聚合时间粒度：小时级趋势比总量更有决策价值
全天总占比可能掩盖峰谷差异。例如 HTTPS 占比全天 85%，但凌晨 3–5 点跌至 62%，说明部分自动化工具或旧客户端仍走 HTTP。
- 按小时提取并聚合字节数或请求数：
awk '{t=substr($4,2); gsub(/:[^:]+$/,"",t); bytes[$t]+=$10} END{for (k in bytes) print k","bytes[k]}' access.log | sort - 将输出导入 Excel 或 Grafana，绘制折线图观察协议切换节奏、后端节点负载波动、Referer 来源潮汐变化
- 对关键时段（如大促开始前1小时）做同比环比，定位策略生效延迟或异常分流
