Nginx 502错误排查：keepalive配置优化实战

1. 问题现象与初步判断

那天下午3点，监控系统突然开始疯狂报警。作为负责线上业务的运维工程师，我的钉钉瞬间被Nginx 502错误的告警消息刷屏。登录Grafana查看监控大盘，发现后端服务的响应时间曲线直接飙到了20秒以上，错误率突破30%大关。

第一反应是检查后端服务是否存活。通过kubectl查看Pod状态，所有服务实例都显示Running，初步排除了服务崩溃的可能性。接着用curl直接测试上游服务接口：

bash复制curl -I http://upstream-service:8080/api/health

返回的HTTP 200表明服务本身是可用的，这让我更加困惑——既然服务没挂，为什么Nginx会报502？

2. 常规排查路径与碰壁经历

2.1 检查基础配置项

首先复查了Nginx最可能出问题的几个配置：

nginx复制proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
keepalive_timeout 75s;

这些超时参数看起来都很合理。尝试将proxy_read_timeout临时调到300秒后重试，502错误依旧。

2.2 日志分析攻坚战

开启Nginx的debug级别日志后，发现了关键线索：

code复制2023/07/15 15:23:17 [error] 18762#0: *3580256 upstream timed out 
(110: Connection timed out) while reading response header from upstream, 
client: 10.2.3.4, server: api.example.com, 
request: "GET /v1/orders HTTP/1.1", 
upstream: "http://10.10.1.2:8080/v1/orders", 
host: "api.example.com"

日志显示是上游服务器响应超时，但之前curl测试明明是通的。这个矛盾点提示问题可能出在特定条件下。

2.3 压力测试复现

使用wrk模拟生产流量：

bash复制wrk -t4 -c100 -d