技能介绍

要解决的问题

排查 Nginx 故障时，最常见的痛点不是配置写错，而是错误日志淹没在海量请求里。一个典型的线上事故：用户反馈部分请求返回 502 或 504，也有人反馈大文件上传直接失败返回 413。运维人员打开 error.log，面对几万行重复的 upstream prematurely closed connection 或 client intended to send too large body，很难快速区分：这到底是后端服务挂了、超时配置不合理，还是单纯文件超过了 client_max_body_size？

更麻烦的是，错误日志和访问日志是两份独立的数据，需要人工交叉比对才能还原「哪个时间点、哪类请求、触发了哪类错误」的完整链路。

核心能力

这个技能的工作方式分为三层：

日志解析：同时读取 error.log 与 access.log，从中提取与 502、504、413 相关的错误条目，自动归类错误模式，而不是简单地全文 grep。
实时可视化：借助 GoAccess 将访问日志渲染为实时统计视图，让请求量峰值、状态码分布、高频来源一目了然，快速定位异常发生在哪个时间段、集中在哪类路径上。
配置校验：集成 nginx -t 做语法与配置有效性检查。很多 502/504 的根源是 upstream 配置错误或共享内存区未分配，光看日志无法确认，需要在改动配置后立即验证。

典型排查路径：先看 GoAccess 的状态码分布确认错误规模 → 再过滤 error log 提取关键错误行 → 最后跑 nginx -t 验证配置是否自洽，据此给出修复建议。

适用边界与注意点

该技能聚焦于三类高频错误（502、504、413）的分析与定位，其他错误码需要自行扩展日志过滤规则。
Nginx 的部分指令依赖共享内存区（如限流 limit_req_zone、limit_conn_zone）。如果目标 Nginx 实例没有分配足够的 zone，日志里会持续报相关错误，这时需要先调整配置再谈修复。
社区版 Nginx 的行为与官方发行版存在差异，生产环境建议以官方包或自行编译的稳定版本为准，排查结论也要结合实际编译参数。
日志分析的准确性取决于日志格式配置。如果修改过 log_format，需要在分析前确认字段对齐，否则状态码或请求耗时统计会失真。