直接查看nginx access.log中$statuscode可快速识别异常请求分布：4xx表客户端问题，5xx表服务端故障；通过awk命令统计占比、按小时分析趋势、过滤假异常（如404/444），再结合error.log定位根因。
直接看日志里的 $status 状态码，就能快速摸清异常请求的分布——4xx 代表客户端问题（比如错链接、权限不足），5xx 是服务端出错（如后端挂了、超时）。统计这两类占比，能帮你第一时间判断是前端调用有问题，还是后端服务扛不住。
从 access.log 提取状态码并分类计数
Nginx 默认 access log 中的 $status 字段记录了每次响应的 HTTP 状态码。只要日志格式包含它（标准配置通常都有），就可以用命令行快速聚合：
- 统计全部 4xx 请求次数：
awk '$9 ~ /^4[0-9]{2}$/ {count++} END {print "4xx:", count+0}' /var/log/nginx/access.log - 统计全部 5xx 请求次数：
awk '$9 ~ /^5[0-9]{2}$/ {count++} END {print "5xx:", count+0}' /var/log/nginx/access.log - 一行算出两者占比（假设总请求数已知或可补）：
awk '{s[$9]++} END {four=0; five=0; for (i in s) {if (i ~ /^4[0-9]{2}$/) four+=s[i]; else if (i ~ /^5[0-9]{2}$/) five+=s[i]} total=four+five; if(total>0) printf "4xx: %.1f%%, 5xx: %.1f%%\n", four/total*100, five/total*100}' /var/log/nginx/access.log
按时间窗口动态观察异常趋势
单看总量不够，要结合时间分析是否突发或持续。如果日志里有 $time_local（默认存在），可用以下方式分小时统计：
- 提取每小时的 4xx/5xx 数量：
awk -F'[' '{gsub(/]/,"",$2); print substr($2,1,13), $9}' /var/log/nginx/access.log | awk '$2 ~ /^4[0-9]{2}$/ {h4[$1]++} $2 ~ /^5[0-9]{2}$/ {h5[$1]++} END {for (t in h4) print t, "4xx:", h4[t], "5xx:", h5[t]+0}' | sort - 重点关注突增时段，再结合该时段的 error.log 或 upstream_response_time 判断是上游超时、连接拒绝，还是应用返回了明确错误码（如 401、503）
区分真实异常与“假 4xx/5xx”
不是所有 4xx/5xx 都算故障。有些是预期行为，需过滤后再分析：
- 404：大量出现可能意味着爬虫扫路径、前端路由错误或旧链接未下线，不一定反映服务问题
- 401/403：常由鉴权中间件返回，需结合是否来自可信来源或特定接口判断
- 502/503/504：才是真正值得关注的服务端异常——502 是 upstream 拒绝连接，503 往往是 upstream 主动返回，504 表示 Nginx 等待 upstream 超时
- 建议先排除 404 和 444（Nginx 主动拒绝），再聚焦 400/401/403/429 以及全部 5xx
配合 error.log 定位根因
access.log 告诉你“哪里错了”，error.log 才告诉你“为什么错”。例如：
- 看到大量 502 → 查 error.log 中是否有
connect() failed或no live upstreams - 看到大量 504 → 搜索
upstream timed out，再核对 proxy_read_timeout 设置是否合理 - 看到 499（客户端主动断连）激增 → 可能是前端取消请求或网络不稳定，不是 Nginx 或后端问题
不复杂但容易忽略：确保 log_format 包含 $status，且没有被自定义格式意外覆盖；线上排查优先用最近几小时日志，避免全量扫描拖慢响应。
