技能介绍

要解决的问题

排查 Nginx 故障时，最直接的线索往往躺在 error.log 里：一次上游超时会抛出 upstream timed out，一次 TLS 客户端版本过低会留下 SSL handshake failure，而配置里 proxy_pass 指向的后端不通时则会刷出 502 Bad Gateway。问题在于，日志只告诉你「发生了什么」，要定位「为什么会发生」还需要把出错配置、upstream 定义和后端健康状态拼在一起看。人工翻配置文件、grep 日志、登录后端机器确认端口，很容易在凌晨的告警里漏掉关键上下文。

这个技能针对的正是这三类高频故障：

502 Bad Gateway：后端拒绝连接或端口未监听
SSL 握手失败：证书、协议版本或 cipher 不匹配
上游超时：proxy_read_timeout 与后端实际耗时不匹配

它如何工作

核心思路是把诊断过程串成一条可复现的链路，而不是简单打印日志：

配置提取：通过 nginx -T 拿到当前生效的完整配置快照，避免在多份 nginx.conf 和 conf.d/ 之间手工比对
日志模式匹配：按错误类型对 error.log 做模式识别，筛出与故障时间窗口匹配的条目
上游状态查询：在 Nginx Plus 环境下调用 REST API 的 /api/8/http/upstreams 端点，确认后端节点的当前状态和健康情况

三步结果放在一起，就能判断故障是出在 Nginx 配置、上游服务还是 TLS 协商链路上。

适用边界与注意点

这个技能适合已经有明确错误日志的事后诊断，不是通用的配置校验工具。它不负责生成 nginx.conf，也不替代压测和监控。

另外，技能文档引用了 Nginx 上游 README.md，其中提到 make 相关的编译与模块配置流程，意味着部分场景需要自行构建 Nginx，而不是直接用发行版包。共享内存区（shared memory zones）在 rate limiting 等功能里是必需的，nginx -T 看到的是运行中进程的配置，不会反映未加载的模块。