直接在Nginx日志中记录$status和$body_bytes_sent是评估流量最基础关键的一步；二者分别表示HTTP状态码和实际发送的响应体字节数，无需额外模块，只需确认log_format中已包含即可。
直接在日志里记录响应状态码和发送字节数，是评估流量最基础也最关键的一步。Nginx 默认日志格式 already 包含这两个字段：$status 和 $body_bytes_sent，无需额外开启模块，只要确认配置正确就能用。
确认日志格式中已包含关键字段
检查 nginx.conf 的 http 块中 log_format 定义，确保包含以下两个变量：
- $status：服务器返回给客户端的 HTTP 状态码（如 200、404、502）
- $body_bytes_sent：实际发送给客户端的响应体字节数（不含响应头）
标准 main 格式通常已满足，例如：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"';用 $body_bytes_sent 评估真实流量压力
这个值反映的是“发出去”的数据量，可直接用于：
- 计算每小时/每日总出流量（单位换算后累加）
- 识别大文件下载或图片资源请求（如单次 >1MB 可单独提取分析）
- 对比不同 URL 的带宽消耗，辅助 CDN 或压缩策略优化
注意：它不包括响应头大小。若需更精确的网络层流量，可配合 $bytes_sent（含响应头）使用。
结合 $status 分析流量质量
状态码不是只看 200，要分层解读：
- 2xx 成功类：主流量来源，但也要关注 206（断点续传）是否异常增多
- 3xx 重定向类：过多说明跳转链路冗长，影响用户体验和 SEO
- 4xx 客户端错误：重点查 404（资源缺失）、429（限流触发），可定位前端链接错误或爬虫恶意扫描
- 5xx 服务端错误：4xx 是用户问题，5xx 是你自己的问题，尤其 502/504 直接指向 upstream 不可用或超时
建议定期跑统计命令，比如：
awk '{print $9}' access.log | sort | uniq -c | sort -nr
进阶：补充响应时间与上游状态提升判断精度
仅靠 $status + $body_bytes_sent 能看“量”和“结果”，但看不出“为什么”。推荐追加两个变量：
- $request_time：整个请求处理耗时（从读完请求头到发完响应），判断慢请求
- $upstream_status：后端真实返回的状态码（如 Nginx 自己返回 502 时，$status=502，但 $upstream_status=-；而真正后端挂了，$upstream_status=502）
这样就能区分问题是出在 Nginx 层（如配置错误、超时设置过短），还是后端服务本身（如数据库崩、API 超时）。
