监控告警：Nginx 502错误率飙升到5%。

看了眼后端服务，运行正常，没有报错。重启Nginx，好了一会又开始502。

排查了3个小时，最后发现是upstream配置的问题。记录一下排查过程。

---

## 问题现象

**监控数据**：

- 502错误率：从0.1% → 5%
- 后端服务：正常运行，无报错
- CPU/内存：正常
- 发生时间：流量高峰期

**特点**：

- 不是全部请求都502，大部分正常
- 重启Nginx后短暂恢复，然后又出现
- 后端服务日志没有异常

---

## 排查过程

### Step 1：看Nginx错误日志

```bash
tail -f /var/log/nginx/error.log
```

发现大量这样的错误：

```
upstream timed out (110: Connection timed out) while connecting to upstream
upstream prematurely closed connection while reading response header
```

**关键信息**：是upstream连接的问题，不是后端服务本身的问题。

### Step 2：检查后端服务状态

```bash
# 查看后端服务进程
ps aux | grep java

# 查看端口监听
ss -tlnp | grep 8080

# 直接测试后端
curl -I http://127.0.0.1:8080/health
```

后端服务正常，直接访问返回200。

### Step 3：检查连接数

```bash
# 查看Nginx到后端的连接数
ss -ant | grep 8080 | wc -l

# 查看连接状态分布
ss -ant | grep 8080 | awk '{print $1}' | sort | uniq -c
```

发现问题了：

```
850 ESTABLISHED
   120 TIME_WAIT
    50 SYN_SENT
```

有50个连接卡在`SYN_SENT`状态，说明Nginx到后端的新连接建立不上。

### Step 4：检查后端连接队列

```bash
# 查看后端服务的accept队列
ss -lnt | grep 8080
```

输出：

```
State    Recv-Q   Send-Q   Local Address:Port
LISTEN   129      128      0.0.0.0:8080
```

**问题找到了！** `Recv-Q`是129，`Send-Q`是128。

这说明accept队列满了（128是默认值），新连接无法被接受。

---

## 根因分析

### 什么是accept队列

```
客户端 → SYN → 服务端（半连接队列）
服务端 → SYN+ACK → 客户端
客户端 → ACK → 服务端（全连接队列/accept队列）
应用程序 accept() → 取出连接
```

当accept队列满了，新的完成三次握手的连接无法进入队列，客户端会收到超时或RST。

### 为什么队列满了

后端是Spring Boot应用，默认配置：

```yaml
server:
  tomcat:
    accept-count: 100  # Tomcat的accept队列
```

而系统层面的限制是`net.core.somaxconn = 128`，取两者较小值，所以实际accept队列只有128。

**流量高峰时**：

1. 请求量大，新连接多
2. accept队列128不够用
3. 新连接被拒绝
4. Nginx收到超时，返回502

---

## 解决方案

### 方案一：调大系统参数

```bash
# 查看当前值
sysctl net.core.somaxconn

# 临时修改
sysctl -w net.core.somaxconn=65535

# 永久修改
echo "net.core.somaxconn = 65535" >> /etc/sysctl.conf
sysctl -p
```

### 方案二：调整Tomcat配置

```yaml
server:
  tomcat:
    accept-count: 1000      # accept队列大小
    max-connections: 10000  # 最大连接数
    threads:
      max: 500              # 最大工作线程数
```

### 方案三：Nginx upstream优化

```nginx
upstream backend {
    server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
    
    keepalive 100;  # 保持连接数，减少新建连接
}

server {
    location / {
        proxy_pass http://backend;
        
        proxy_connect_timeout 5s;      # 连接超时
        proxy_read_timeout 60s;        # 读取超时
        proxy_send_timeout 60s;        # 发送超时
        
        proxy_http_version 1.1;        # 使用HTTP/1.1
        proxy_set_header Connection ""; # 配合keepalive
    }
}
```

### 方案四：多实例负载均衡

如果单实例撑不住，可以部署多实例：

```nginx
upstream backend {
    least_conn;  # 最少连接数策略
    
    server 127.0.0.1:8080 weight=1;
    server 127.0.0.1:8081 weight=1;
    server 127.0.0.1:8082 weight=1;
    
    keepalive 100;
}
```

---

## 最终配置

**系统参数**（/etc/sysctl.conf）：

```bash
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 65535
```

**Spring Boot配置**：

```yaml
server:
  tomcat:
    accept-count: 2000
    max-connections: 20000
    threads:
      max: 500
      min-spare: 50
```

**Nginx配置**：

```nginx
upstream backend {
    server 127.0.0.1:8080;
    keepalive 200;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}
```

---

## 优化效果

| 指标 | 优化前 | 优化后 |
|------|--------|--------|
| 502错误率 | 5% | 0.01% |
| accept队列溢出 | 频繁 | 无 |
| 连接建立时间 | 不稳定 | 稳定<5ms |

---

## 排查命令汇总

```bash
# 查看Nginx错误日志
tail -f /var/log/nginx/error.log

# 查看连接状态
ss -ant | grep <端口>

# 查看监听队列
ss -lnt | grep <端口>

# 查看队列溢出统计
netstat -s | grep -i listen

# 查看系统参数
sysctl net.core.somaxconn

# 实时监控连接数
watch -n 1 'ss -ant | grep <端口> | wc -l'
```

---

## 经验总结

| 502原因 | 排查方向 |
|---------|----------|
| upstream timed out | 后端处理慢或连接队列满 |
| connection refused | 后端服务没启动 |
| no live upstreams | 所有后端都不可用 |
| prematurely closed | 后端主动断开连接 |

**这次的坑**：后端服务看起来正常，但accept队列满了，新连接进不来。

**教训**：

1. 系统默认的`somaxconn=128`太小，生产环境必须调大
2. Nginx配置`keepalive`可以减少新建连接，降低队列压力
3. 监控要加上连接队列指标

有问题评论区交流~




当accept队列满了，新的完成三次握手的连接无法进入队列，客户端会收到超时或RST。

线上Nginx频繁502，排查3小时发现是这个配置的问题

运维

网络与通信

后端

Nginx502错误率飙升排查实录：发现后端服务accept队列溢出导致连接超时。通过调整系统参数net.core.somaxconn、优化Tomcat配置和Nginx upstream keepalive设置，502错误率从5%降至0.01%。详细记录排查过程与解决方案，包括关键命令和配置优化建议。

负载均衡

AI驱动 智领未来

5位重磅专家聚焦 AI 时代开发者核心成长需求，带你深入解锁全栈进化、人机协作关键路径！点击报名到场：<a href="https://cloud.tencent.com/developer/salon/salon-2403/signup" target="_blank">https://cloud.tencent.com/developer/salon/salon-2403/signup</a><br/> 
 <img src="https://qcloudimg.tencent-cloud.cn/raw/487c82639d2338df3ef66dfb1450601a.png"/>

腾讯技术创作特训营「年度论坛」正在报名中！

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

线上Nginx频繁502，排查3小时发现是这个配置的问题-腾讯云开发者社区-腾讯云

线上Nginx频繁502，排查3小时发现是这个配置的问题

线上Nginx频繁502，排查3小时发现是这个配置的问题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐