線上服務(wù) 502、504、Connection Reset 到底怎么排查？

問題背景

在生產(chǎn)環(huán)境中，502、504 和 Connection Reset 是 Nginx 反向代理場(chǎng)景下最常見的三類錯(cuò)誤。它們經(jīng)常被籠統(tǒng)地歸為"后端掛了"，但實(shí)際上三種錯(cuò)誤指向完全不同的故障類型：

502 Bad Gateway：后端無響應(yīng)

504 Gateway Timeout：后端響應(yīng)太慢

Connection Reset：連接被中間層或后端主動(dòng)斷開

三種錯(cuò)誤的排查路徑不同，錯(cuò)誤日志中的關(guān)鍵詞也不同。如果在 504 的場(chǎng)景下用 502 的思路去排查（比如反復(fù)檢查后端進(jìn)程是否存活），就會(huì)浪費(fèi)大量時(shí)間。

本文以 Nginx 作為反向代理層為默認(rèn)場(chǎng)景，覆蓋從錯(cuò)誤特征區(qū)分到鏈路逐段排查的完整方法。

一、三種錯(cuò)誤的本質(zhì)區(qū)分

1.1 通信鏈路

從客戶端請(qǐng)求到后端響應(yīng)，數(shù)據(jù)經(jīng)過以下路徑：

客戶端 → Nginx（反向代理） → upstream（后端服務(wù)）
    ↑          ↑
  問題發(fā)生在      問題發(fā)生在
  客戶端→Nginx     Nginx→upstream

1.2 錯(cuò)誤特征對(duì)比

1.3 快速判斷方法

在生產(chǎn)環(huán)境中，不要只看瀏覽器或客戶端返回的錯(cuò)誤碼，因?yàn)闉g覽器可能緩存或展示不準(zhǔn)確。正確的做法是：

# 1. 查看 Nginx access.log 中 $status 字段的實(shí)際狀態(tài)碼
$ awk'{print $9}'/var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
 5234 200
  102 502
  56 504
  12 499

# 2. 結(jié)合 upstream_status 看后端實(shí)際返回了什么
$ tail -100 /var/log/nginx/access.log | grep"status=502"| head -5
# 注意：upstream_status 在 502 時(shí)可能為空（沒連上），在 504 時(shí)可能是 504

# 3. 直接查看 Nginx error.log 中的錯(cuò)誤類型
$ grep -E"connect() failed|upstream timed out|recv() failed|Connection reset|no live upstreams"/var/log/nginx/error.log | tail -20

注意：access.log 中的$status是 Nginx 返回給客戶端的響應(yīng)碼，$upstream_status是 upstream 返回給 Nginx 的響應(yīng)碼。兩者可能不同——比如 Nginx 檢測(cè)到 upstream 超時(shí)會(huì)返回 504，但 upstream 實(shí)際返回的是 200（只是還沒來得及發(fā)給 Nginx 就超時(shí)了）。

二、四段鏈路排查法

無論哪種錯(cuò)誤，排查思路都是"分段確認(rèn)，定位最短的板"。將請(qǐng)求鏈路拆為四段：

段1: 客戶端 → Nginx 網(wǎng)絡(luò)
段2: Nginx 自身
段3: Nginx → upstream 網(wǎng)絡(luò)
段4: upstream（后端服務(wù)）

2.1 本機(jī)對(duì)照法

在 Nginx 部署的機(jī)器上執(zhí)行 curl，排除客戶端到 Nginx 的網(wǎng)絡(luò)問題：

# 對(duì)本機(jī) Nginx 發(fā)請(qǐng)求（不走外網(wǎng)）
$ curl -sS -o /dev/null -w'http_code=%{http_code} time_total=%{time_total}s time_connect=%{time_connect}s time_starttransfer=%{time_starttransfer}s
'http://127.0.0.1/health

本機(jī) curl 正常、外部訪問異常 → 段1 的問題

本機(jī) curl 也異常 → 段2~4 的問題

2.2 直連 upstream 法

跳過 Nginx，直接訪問后端服務(wù)：

# 直連 upstream（從 Nginx 機(jī)器上執(zhí)行）
$ curl -sS -o /dev/null -w"http_code=%{http_code} time_total=%{time_total}s
"http://10.0.1.10:8080/health

# 如果 upstream 不止一個(gè)，逐個(gè)測(cè)試
$foripin10.0.1.10 10.0.1.11 10.0.1.12;do
 echo-n"$ip: "
  curl -sS -o /dev/null -w"code=%{http_code} total=%{time_total}s
"--connect-timeout 3 --max-time 5 http://$ip:8080/health
done

本機(jī) Nginx 異常、直連 upstream 也異常 → 段4 的問題

本機(jī) Nginx 異常、直連 upstream 正常 → 段2~3 的問題（Nginx 配置或 Nginx→upstream 網(wǎng)絡(luò)）

三、502 Bad Gateway 專項(xiàng)排查

3.1 日志關(guān)鍵定位

# 查看最近 502 對(duì)應(yīng)的 error 日志
$ grep" 502 "/var/log/nginx/access.log | tail -5 | awk'{print $1,$4,$7}'

# 查看 error.log 中與 502 相關(guān)的錯(cuò)誤
$ grep"connect() failed"/var/log/nginx/error.log | tail -10
2025/08/15 1422 [error] 1234#0: *56789 connect() failed (111: Connection refused) while connecting to upstream, client: 1.2.3.4, server: api.example.com, upstream: "http://10.0.1.10:8080/api/", host: "api.example.com"

3.2 常見原因與排查

原因 A：后端進(jìn)程未啟動(dòng)或崩潰

# 確認(rèn)后端進(jìn)程是否存活
$ ps aux | grep -E"java|python|node|php-fpm"| grep -v grep

# 確認(rèn)端口在監(jiān)聽
$ ss -lntp | grep 8080

# 查看后端進(jìn)程是否被 OOM kill
$ dmesg -T | grep -i"oom|killed"| tail -5

原因 B：PHP-FPM 進(jìn)程池耗盡

# PHP-FPM 狀態(tài)（如果已開啟 status page）
$ curl http://127.0.0.1/status

# 或查看 PHP-FPM 日志
$ tail -50 /var/log/php-fpm/www-error.log
WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers)
WARNING: [pool www] server reached pm.max_children setting (50), consider raising it

原因 C：防火墻或安全組攔截

# 確認(rèn) Nginx → upstream 端口可通
$ telnet 10.0.1.10 8080
$ nc -zv 10.0.1.10 8080

# 檢查 iptables 規(guī)則
$ iptables -L -n | grep 8080

# 檢查云廠商安全組（需在云控制臺(tái)確認(rèn)）

原因 D：FastCGI Buffer 不足

# error.log 關(guān)鍵字
grep"upstream sent too big header"/var/log/nginx/error.log

# 解決：增大 buffer
location ~ .php$ {
  fastcgi_buffer_size 32k;
  fastcgi_buffers 8 32k;
  fastcgi_busy_buffers_size 64k;
  ...
}

3.3 502 排查 checklist

# 1. 后端進(jìn)程是否運(yùn)行
ps aux | grep backend

# 2. 端口是否監(jiān)聽
ss -lntp

# 3. 防火墻是否攔截
iptables -L -n

# 4. Nginx proxy_pass 地址是否寫對(duì)
grep"proxy_pass|fastcgi_pass"/etc/nginx/conf.d/default.conf

# 5. upstream 主機(jī)名能否解析（如果用的是域名）
nslookup backend.example.com

# 6. 后端是否有健康檢查接口
curl -I http://127.0.0.1:8080/health

四、504 Gateway Timeout 專項(xiàng)排查

4.1 超時(shí)時(shí)間的配置解析

Nginx 反向代理涉及三個(gè)超時(shí)配置：

location /api/ {
  proxy_connect_timeout 5s;   # 與 upstream 建立 TCP 連接的超時(shí)
  proxy_send_timeout 10s;    # 發(fā)送請(qǐng)求體到 upstream 的超時(shí)
  proxy_read_timeout 30s;    # 等待 upstream 返回響應(yīng)的超時(shí)（最常碰到）
  proxy_pass http://backend;
}

504 最常見的原因是proxy_read_timeout不夠——Nginx 已經(jīng)將請(qǐng)求發(fā)送給 upstream，但在proxy_read_timeout時(shí)間內(nèi) upstream 沒有返回完整的響應(yīng)頭部。

Nginx 的默認(rèn)值：proxy_connect_timeout60s、proxy_send_timeout60s、proxy_read_timeout60s。但在生產(chǎn)環(huán)境中，這些默認(rèn)值不一定合理。

4.2 排查步驟

Step 1：測(cè)量 upstream 的真實(shí)響應(yīng)時(shí)間

# 使用 curl 的 -w 選項(xiàng)提取各階段耗時(shí)
$ curl -sS -o /dev/null -w"
 time_namelookup=%{time_namelookup}s

 time_connect=%{time_connect}s

 time_starttransfer=%{time_starttransfer}s

 time_total=%{time_total}s
"
 http://10.0.1.10:8080/api/slow-endpoint

time_namelookup=0.001s     # DNS 解析耗時(shí)
time_connect=0.002s      # TCP 建連耗時(shí)
time_starttransfer=25.300s   # 從開始到收到第一個(gè)字節(jié)的耗時(shí)
time_total=25.400s       # 總耗時(shí)

如果time_starttransfer很大（比如 > 30s），說明 upstream 處理請(qǐng)求的時(shí)間很長(zhǎng)，Nginx 的proxy_read_timeout需要大于這個(gè)值。

Step 2：檢查 error.log 中的超時(shí)日志

$ grep"upstream timed out"/var/log/nginx/error.log | tail -5
2025/08/15 1422 [error] 1234#0: *57123 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 1.2.3.4, server: api.example.com, upstream: "http://10.0.1.10:8080/api/slow", host: "api.example.com"

Step 3：按接口類型拆分超時(shí)配置

不要全局統(tǒng)一超時(shí)，不同接口的預(yù)期處理時(shí)間不同：

# 普通 API：快速響應(yīng)，5 秒超時(shí)
location /api/quick/ {
  proxy_read_timeout 5s;
  proxy_pass http://backend;
}

# 報(bào)表導(dǎo)出：可能耗時(shí)較長(zhǎng)，120 秒超時(shí)
location /api/export/ {
  proxy_read_timeout 120s;
  proxy_pass http://backend;
}

# 長(zhǎng)輪詢/SSE：超時(shí)時(shí)間設(shè)長(zhǎng)
location /api/poll/ {
  proxy_read_timeout 3600s;
  proxy_buffering off;      # 長(zhǎng)輪詢關(guān)閉緩沖
  proxy_pass http://backend;
}

4.3 后端慢的常見根因

后端在proxy_read_timeout內(nèi)未返回響應(yīng)，根本原因是后端處理太慢，常見原因：

504 的解決方向有兩個(gè)：一是優(yōu)化后端響應(yīng)速度（治本），二是增大proxy_read_timeout（治標(biāo)）。如果后端無法短期內(nèi)優(yōu)化，先增大 timeout 確保業(yè)務(wù)可用，再排期優(yōu)化后端性能。

五、Connection Reset 專項(xiàng)排查

5.1 錯(cuò)誤的本質(zhì)

Connection Reset（104: Connection reset by peer）不同于 502 和 504，它的本質(zhì)是通信的一方在沒有正常完成四次揮手的情況下，直接發(fā)送了 RST 包。

在 Nginx 場(chǎng)景下，這通常意味著：

upstream 主動(dòng)斷開連接（最常見）：后端壓力過大，主動(dòng)關(guān)閉連接

Nginx 主動(dòng)斷開連接：Nginx 側(cè)超時(shí)或連接池回收

中間網(wǎng)絡(luò)設(shè)備斷開：防火墻、負(fù)載均衡器的 idle timeout 設(shè)置過小

5.2 排查步驟

Step 1：確認(rèn)報(bào)錯(cuò)位置

Nginx error.log 會(huì)明確告訴你是哪一端 reset 了連接：

# upstream reset 連接
$ grep"Connection reset by peer"/var/log/nginx/error.log
2025/08/15 1422 [error] 1234#0: *57123 recv() failed (104: Connection reset by peer) while reading response header from upstream, ...

# Nginx 主動(dòng) reset 連接（較少見）
# 不會(huì)在 error.log 中出現(xiàn)，但 clients 端會(huì)報(bào) "Connection reset by peer"

Step 2：檢查 upstream 的 fd 和線程池

Connection Reset 最常見的根因是 upstream 的文件描述符（fd）耗盡或線程池打滿，導(dǎo)致新連接被拒絕或已有連接被強(qiáng)制關(guān)閉。

# upstream 服務(wù)器上檢查 fd
$ cat /proc/$(pidof java)/limits | grep"open files"
$ lsof -p $(pidof java) | wc -l

# 檢查 TCP 連接隊(duì)列
$ ss -ant | grep -E'SYN-RECV|TIME-WAIT'| wc -l
$ netstat -s | grep -i"listen overflow"

Step 3：檢查 Nginx 的 worker_connections

# Nginx 連接數(shù)是否打滿
$ curl http://127.0.0.1/nginx_status # 需要開啟 stub_status
Active connections: 65300
server accepts handled requests
123456 123456 345678
Reading: 0 Writing: 128 Waiting: 45

如果Active connections接近worker_connections × worker_processes，說明 Nginx 自身連接數(shù)緊張。

Step 4：檢查 TCP backlog 是否溢出

# 查看 listen 隊(duì)列溢出情況
$ netstat -s | grep -i"listen"
  18932timesthe listen queue of a socket overflowed

# 當(dāng)前 backlog 大小
$ ss -lntp | grep 80
LISTEN 0 511 ...

# 第一個(gè)數(shù)字 511 = backlog 大小

如果 backlog 溢出頻繁，調(diào)大配置：

listen 8080 backlog=65535;

配合內(nèi)核參數(shù)：

$ sysctl -w net.core.somaxconn=65535
$ sysctl -w net.ipv4.tcp_max_syn_backlog=65535

六、Nginx 配置優(yōu)化參考

6.1 合理的超時(shí)與緩沖配置

upstream backend {
  # 負(fù)載均衡算法
  least_conn;

  # upstream 節(jié)點(diǎn)
  server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
  server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;

  # 長(zhǎng)連接池
  keepalive 128;
  keepalive_requests 10000;
  keepalive_timeout 60s;
}

server {
  listen 80 backlog=65535;
  server_name api.example.com;

  # 超時(shí)配置
  proxy_connect_timeout 5s;
  proxy_send_timeout 10s;
  proxy_read_timeout 30s;

  # 緩沖配置
  proxy_buffer_size 4k;
  proxy_buffers 8 4k;
  proxy_busy_buffers_size 8k;

  # 請(qǐng)求體大小
  client_max_body_size 10m;
  client_body_buffer_size 128k;

  location /api/ {
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_pass http://backend;
  }
}

6.2 日志格式必須包含 upstream 信息

log_format main_ext '$remote_addr - $remote_user [$time_local] '
          '"$request" $status $body_bytes_sent '
          '"$http_referer" "$http_user_agent" '
          'upstream_addr=$upstream_addr '
          'upstream_status=$upstream_status '
          'upstream_response_time=$upstream_response_time '
          'request_time=$request_time';

access_log /var/log/nginx/access.log main_ext;

這些 upstream 變量是排查 502/504/Connection Reset 的關(guān)鍵：

$upstream_addr：實(shí)際處理請(qǐng)求的 upstream 地址

$upstream_status：upstream 返回的狀態(tài)碼

$upstream_response_time：upstream 處理耗時(shí)（秒）

$request_time：Nginx 總耗時(shí)（含網(wǎng)絡(luò)延遲）

如果日志中沒有這些字段，遇到問題就只能靠猜。

6.3 故障轉(zhuǎn)移和降級(jí)

upstream backend {
  server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
  server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
  server 10.0.1.12:8080 backup;   # 備用節(jié)點(diǎn)
}

server {
  location /api/ {
    proxy_pass http://backend;
    proxy_next_upstream error timeout http_502 http_503 http_504;
    proxy_next_upstream_tries 2;  # 重試 2 次
    proxy_next_upstream_timeout 5s; # 重試總時(shí)長(zhǎng)限制

    # 降級(jí)兜底頁(yè)面
    error_page 502 504 = @fallback;
  }

  location @fallback {
    internal;
    default_type application/json;
    return 200 '{"status":"degraded","message":"服務(wù)暫時(shí)不可用，請(qǐng)稍后重試"}';
  }
}

proxy_next_upstream_tries不要設(shè)置太大（建議 2~3），否則故障時(shí)大量重試會(huì)加劇上游負(fù)載，形成雪崩。

七、常見場(chǎng)景速查

八、生產(chǎn)環(huán)境注意事項(xiàng)

配置修改前必須備份：

$ cp -a /etc/nginx /etc/nginx.$(date +%F_%H%M%S).bak

執(zhí)行配置重載而非重啟：先用nginx -t測(cè)試配置文件語法，再執(zhí)行nginx -s reload熱加載。不要用systemctl restart nginx，這會(huì)中斷正在處理的連接。

超時(shí)配置不要全局一刀切：不同接口的預(yù)期響應(yīng)時(shí)間不同，根據(jù)接口 SLA 分別配置proxy_read_timeout。

關(guān)閉 proxy_buffering 的場(chǎng)景：長(zhǎng)輪詢、SSE、Server-Sent Events 等場(chǎng)景需要關(guān)閉緩沖，否則 Nginx 會(huì)等緩沖區(qū)滿了才轉(zhuǎn)發(fā)數(shù)據(jù)。

注意 proxy_next_upstream 的重試風(fēng)險(xiǎn)：proxy_next_upstream在 post 請(qǐng)求時(shí)可能導(dǎo)致重復(fù)提交。如果后端不是冪等的，考慮用proxy_next_upstream error timeout而非proxy_next_upstream http_500。

505 錯(cuò)誤之外的排查：如果看到 499 錯(cuò)誤（Nginx 的客戶端主動(dòng)斷開連接碼），說明客戶端等不及 Nginx 響應(yīng)就斷開了，通常是瀏覽器超時(shí)或前端設(shè)置了 timeout。

九、總結(jié)

502、504、Connection Reset 的排查不是靠"重啟大法"，而是靠日志和數(shù)據(jù)驅(qū)動(dòng)的分段排查：

日志先行：先看 Nginx error.log 中的錯(cuò)誤關(guān)鍵詞，是什么錯(cuò)誤、發(fā)生在哪一段

分層驗(yàn)證：本機(jī) curl → 直連 upstream → 逐層確認(rèn)問題在哪一段

對(duì)癥下藥：

502 查后端存活和防火墻

504 查后端響應(yīng)時(shí)間和超時(shí)配置

Connection Reset 查后端 fd 和線程池

最后，所有的排查前提是日志配置了充分的字段。如果 access.log 中沒有$upstream_addr、$upstream_status、$upstream_response_time，排查效率會(huì)大幅降低。建議所有 Nginx 反向代理的日志配置第一件事就是把這些字段加進(jìn)去。