腳本之家服務器常用軟件

快捷導航

線上Nginx頻繁502的排查過程與解決方案

更新時間：2026年01月27日 09:53:44 作者：白露與泡影

本文詳細介紹了在線上Nginx頻繁出現(xiàn)502錯誤的排查過程,包括監(jiān)控數(shù)據(jù)、Nginx和后端服務的狀態(tài)檢查、連接數(shù)分析以及最終的解決方案,作者通過調整系統(tǒng)參數(shù)、優(yōu)化Nginx配置和多實例負載均衡等措施,成功解決了502錯誤問題,需要的朋友可以參考下

問題現(xiàn)象

監(jiān)控數(shù)據(jù)：

502錯誤率：從0.1% → 5%
后端服務：正常運行，無報錯
CPU/內存：正常
發(fā)生時間：流量高峰期

特點：

不是全部請求都502，大部分正常
重啟Nginx后短暫恢復，然后又出現(xiàn)
后端服務日志沒有異常

排查過程

Step 1：看Nginx錯誤日志

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

發(fā)現(xiàn)大量這樣的錯誤：

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

關鍵信息：是upstream連接的問題，不是后端服務本身的問題。

Step 2：檢查后端服務狀態(tài)

# 查看后端服務進程
ps aux | grep java

# 查看端口監(jiān)聽
ss -tlnp | grep 8080

# 直接測試后端
curl -I http://127.0.0.1:8080/health

后端服務正常，直接訪問返回200。

Step 3：檢查連接數(shù)

# 查看Nginx到后端的連接數(shù)
ss -ant | grep 8080 | wc -l

# 查看連接狀態(tài)分布
ss -ant | grep 8080 | awk '{print $1}' | sort | uniq -c

發(fā)現(xiàn)問題了：

850 ESTABLISHED
   120 TIME_WAIT
    50 SYN_SENT

有50個連接卡在SYN_SENT狀態(tài)，說明Nginx到后端的新連接建立不上。

Step 4：檢查后端連接隊列

# 查看后端服務的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應用，默認配置：

server:
  tomcat:
    accept-count: 100  # Tomcat的accept隊列

而系統(tǒng)層面的限制是net.core.somaxconn = 128，取兩者較小值，所以實際accept隊列只有128。

流量高峰時：

請求量大，新連接多
accept隊列128不夠用
新連接被拒絕
Nginx收到超時，返回502

解決方案

方案一：調大系統(tǒng)參數(shù)

# 查看當前值
sysctl net.core.somaxconn

# 臨時修改
sysctl -w net.core.somaxconn=65535

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

方案二：調整Tomcat配置

server:
  tomcat:
    accept-count: 1000      # accept隊列大小
    max-connections: 10000  # 最大連接數(shù)
    threads:
      max: 500              # 最大工作線程數(shù)

方案三：Nginx upstream優(yōu)化

upstream backend {
    server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
    
    keepalive 100;  # 保持連接數(shù)，減少新建連接
}

server {
    location / {
        proxy_pass http://backend;
        
        proxy_connect_timeout 5s;      # 連接超時
        proxy_read_timeout 60s;        # 讀取超時
        proxy_send_timeout 60s;        # 發(fā)送超時
        
        proxy_http_version 1.1;        # 使用HTTP/1.1
        proxy_set_header Connection ""; # 配合keepalive
    }
}

方案四：多實例負載均衡

如果單實例撐不住，可以部署多實例：

upstream backend {
    least_conn;  # 最少連接數(shù)策略
    
    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;
}

最終配置

系統(tǒng)參數(shù)（/etc/sysctl.conf）：

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

Spring Boot配置：

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

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;
    }
}

優(yōu)化效果

指標	優(yōu)化前	優(yōu)化后
502錯誤率	5%	0.01%
accept隊列溢出	頻繁	無
連接建立時間	不穩(wěn)定	穩(wěn)定<5ms

排查命令匯總

# 查看Nginx錯誤日志
tail -f /var/log/nginx/error.log

# 查看連接狀態(tài)
ss -ant | grep <端口>

# 查看監(jiān)聽隊列
ss -lnt | grep <端口>

# 查看隊列溢出統(tǒng)計
netstat -s | grep -i listen

# 查看系統(tǒng)參數(shù)
sysctl net.core.somaxconn

# 實時監(jiān)控連接數(shù)
watch -n 1 'ss -ant | grep <端口> | wc -l'

經(jīng)驗總結

502原因	排查方向
upstream timed out	后端處理慢或連接隊列滿
connection refused	后端服務沒啟動
no live upstreams	所有后端都不可用
prematurely closed	后端主動斷開連接

這次的坑：后端服務看起來正常，但accept隊列滿了，新連接進不來。

教訓：