Nginx 报错排查方法论 — 8 步决策树

📅 创建于 2026-07-09 🔄 更新于 2026-07-09 📝 2431 字

nginx troubleshooting methodology networking performance tcp

Nginx 报错排查方法论 — 8 步决策树

来源：马哥Linux运维 | 发布日期：2026-07-07

一套可以在生产环境照搬执行的 Nginx 故障排查套路，覆盖 502/504/499/500/connection reset/TLS 握手失败/reload 不生效等各种报错形态。核心特点：每一步都明确看什么指标、判断什么现象、下一步往哪里收敛。

💡 本文是"方法论/操作流程"视角。如需按主题查阅（字段说明、状态码表、超时参数、案例复盘、安全配置），请参考 nginx-log-analysis-troubleshooting-guide；502/504/RST 专项排查参见 nginx-502-504-connection-reset-guide。

核心洞察

超过一半的"Ngigx 报错"根因不在 Nginx 本身，而在：

上游层：Tomcat/PHP-FPM/Java 应用/后端服务
系统资源层：FD 耗尽、端口耗尽、TIME_WAIT 堆积
TLS 层：握手失败、证书过期、SNI 不匹配
Reload 层：reload 假生效、配置没真正加载

Nginx 只是流量的第一个落点。本文的方法论能稳定地把 7 成以上的 Nginx 故障收敛到一个具体原因。

适用与不适用场景

适用：业务反馈"打不开/偶发打不开"、access.log 状态码异常（4xx/5xx/499）、上游存活但 Nginx 报错、TLS 握手间歇失败、reload 后报错变多、FD 接近上限/TIME_WAIT 异常堆积、上游 HTTPS 自签证书握手失败。

不适用：业务代码自身抛 500（应用 bug）、DDoS/CC 攻击（需限流清洗流程）、Nginx 编译期模块缺失。

四层排查框架

从近用户端往底层走，每一层有明确的"退出指标"：

第一层：确认报错是否在 Nginx
  看 error.log 热点 + access.log 状态码分布 + 监控曲线突变
  ↓ 确认在 Nginx 之后

第二层：缩小范围，区分上游 vs Nginx 自身
  502/504/upstream prematurely closed → 上游层
  connect() failed/no live upstreams/upstream timed out → 上游层
  Too many open files/worker exited on signal → Nginx/系统层

  ↓ 进入

第三层：深入具体组件
  上游层 → upstream 健康状态/后端进程/FD/端口/TLS
  Nginx 层 → worker 数量/FD/reload 状态/配置 include 顺序
  系统层 → ulimit/端口分配/TCP 状态/swap/OOM
  网络层 → 专线抖动/MTU/VPC 安全组

  ↓ 定位后

第四层：做变更
  ⚠️ 变更铁律（三条缺一不可）：
  ① 在灰度机器/同 LB 其他副本上先试
  ② 保留一份可用配置备份 nginx.conf.bak.YYYYMMDD-HHMMSS
  ③ 有一份 5 分钟内可回滚的命令或脚本

8 步实战排查

步骤 1：确认报错是不是在 Nginx

# 看最近 error.log 的等级分布
tail -n 1000 /var/log/nginx/error.log | awk -F'[][]' '{print $4}' | sort | uniq -c | sort -rn | head -20

异常	含义	动作
`[crit]` 出现	SSL 配置/证书问题	跳至步骤 5，查 SSL/TLS
`[emerg]` 出现	master 启动失败或严重配置错误	立即停手排查
完全没有 [error] 但业务报 502	大概率上游层问题	转向步骤 2

步骤 2：拉最近 5-10 分钟 access.log 状态码分布

tail -n 50000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn | head

状态码分布	指向	下一步
502/504 大量	上游层	步骤 3
499 比例飙高	客户端主动断开（上游慢或客户端超时太短）	步骤 5 调 proxy_read_timeout
500 全是 Nginx 主动返回	Nginx 自身层	步骤 4
报错率 < 0.1%	观察即可	报错率 > 1% 立即介入

步骤 3：直接验证上游健康状态

# 从 Nginx 主机直接 curl 上游端口
for ip in $(awk '/upstream/ {flag=1; next} flag && /server/ {print $2}' \
  /etc/nginx/nginx.conf | awk -F: '{print $2}'); do
  echo "=== probe $ip ==="
  curl -sS -o /dev/null -w 'http_code=%{http_code} time_total=%{time_total}\n' \
    --max-time 5 "http://$ip/healthz" || true
done

上游响应	判断	下一步
全部 200，time_total 稳定	上游活着	步骤 4（怀疑 Nginx→上游这一跳）
time_total 5s 已超时	上游响应慢，检查 GC/dump	上游自身排查
connect refused	上游进程没起来或只监听 127.0.0.1	重启上游
部分不可用	某机房/实例问题	网络层排查
全部不可用	后端集群问题	集群恢复

步骤 4：检查 Nginx 到上游的连接数与 FD

master_pid=$(cat /var/run/nginx.pid 2>/dev/null || pgrep -f 'nginx: master' | head -1)
for wpid in $(pgrep -f 'nginx: worker'); do
  fd=$(ls -1 /proc/$wpid/fd 2>/dev/null | wc -l)
  echo "worker pid=$wpid fd=$fd limit=$(cat /proc/$wpid/limits | awk '/open files/{print $4}')"
done
ss -s

异常	修复
worker FD 接近或达到 limit（默认 1024）	调 `worker_rlimit_nofile` + 系统 `ulimit -n`
ESTABLISHED 远超正常值	怀疑连接泄漏或上游慢
TIME-WAIT 比例异常高	短连接场景 — 启用上游 keepalive

步骤 5：把方向收敛到 upstream 段配置

nginx -T 2>/dev/null | awk '/upstream /,/^}/'
nginx -T 2>/dev/null | grep -E 'proxy_(connect|send|read)_timeout|proxy_next_upstream|keepalive'

缺失项	后果	修复
没有 `keepalive`	每次转发都新建 TCP，上游被短连接打爆	`keepalive 64;`
`max_fails=3 fail_timeout=10s`	太敏感，短促抖动就踢出	调为 `fail_timeout=30s`
`proxy_read_timeout` 太短（如 10s）	长请求被 504	30-120s 按业务调整
没有 `proxy_next_upstream`	上游一次失败就返回错误	开启容灾重试

步骤 6：确认 reload 是不是真的成功

reload 失败但 Nginx 仍在跑老配置是线上最常见的"假配置"来源。

nginx -t                    # 语法检查（不可跳过）
nginx -s reload             # 平滑 reload
# 确认 worker 进程启动时间是否刷新
for pid in $(pgrep -f 'nginx: worker'); do
  echo "worker pid=$pid start_time=$(ps -o lstart= -p $pid)"
done

异常	根因	修复
`nginx -t` 报错但 reload 执行了	新配置被丢弃	修语法后重新 reload
worker 启动时间没刷新	systemd 配置错误或 HUP 信号被截获	用 `systemctl reload nginx` 或 `nginx -s reload`
只剩 1 个 worker	`worker_processes` 被改成 1	改回 `auto`
旧 worker 一直不退出	`shutdown_timeout` 太长	调短或手动 kill

步骤 7：检查系统层/进程层资源限制

systemctl show nginx | grep -E 'LimitNOFILE|LimitNPROC'
cat /proc/$(pgrep -f 'nginx: master' | head -1)/limits
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog net.ipv4.ip_local_port_range
ulimit -n

参数	生产建议
`LimitNOFILE`	≥ 100000
`somaxconn`	≥ 4096
`tcp_max_syn_backlog`	≥ 4096
`ip_local_port_range`	1024 65000

步骤 8：变更与验证

改任何一段配置前必须：

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d-%H%M%S)
nginx -t  # 语法检查不可跳过

验证不只看当前 30 秒，要拉 5 分钟、15 分钟、1 小时三个时间窗口的状态码分布，确认没有回弹。

完整排查决策树

现象：业务报"网站打不开 / 慢 / 502 / 504"
 │
 ├─ 步骤 1：error.log 关键词定位
 │    ├─ emerg/alert/crit → 配置/证书/启动层 → 步骤 6/7
 │    └─ error/warn → 步骤 2
 │
 ├─ 步骤 2：access.log 状态码分布
 │    ├─ 502/504/499 大量 → 步骤 3
 │    └─ 500/其它 → 步骤 4/5
 │
 ├─ 步骤 3：上游探活
 │    ├─ 全部失败 → 后端集群问题
 │    ├─ 部分失败 → 网络/机房层
 │    └─ 全部活着 → 步骤 4
 │
 ├─ 步骤 4：Nginx-上游连接/FD
 │    ├─ FD 接近 limit → systemd/ulimit
 │    ├─ 连接数异常 → keepalive/慢上游
 │    └─ 正常 → 步骤 5
 │
 ├─ 步骤 5：upstream 段配置
 │    ├─ 缺 keepalive → 加上
 │    ├─ timeout 不合理 → 调整
 │    └─ proxy_next_upstream 没开 → 开启
 │
 ├─ 步骤 6：reload 是否真生效
 │    ├─ worker 时间戳未变 → 重新 reload
 │    └─ 时间戳已更新 → 步骤 7
 │
 ├─ 步骤 7：系统层资源
 │    ├─ ulimit/somaxconn 偏小 → 调整
 │    └─ 正常 → 步骤 8
 │
 └─ 步骤 8：变更 + 验证
      ├─ 小流量灰度验证
      ├─ 5/15/60 分钟观察
      └─ 恶化立即回滚

报错关键字 → 应急动作快查

凌晨三点被叫醒时按这个来：

现象	第一判断	关键命令	动作
大面积 502	上游不可用	`curl` 上游 + `netstat`	检查上游集群状态
大面积 504	上游慢	`awk -F'urt='` 看上游耗时	调 `proxy_read_timeout` / 上游扩容
大面积 499	客户端超时短	看 Nginx `$request_time` 分布	调客户端 timeout / 上游性能
reload 后配置不生效	没 reload 成功	`nginx -t` + worker 启动时间	`nginx -s reload` 或 `systemctl reload`
`Too many open files`	FD 耗尽	`cat /proc/<pid>/limits`	调 `LimitNOFILE` + `worker_rlimit_nofile`
TLS 握手失败	上游/客户端 TLS 配置	`openssl s_client -status`	调整 `proxy_ssl_*`
WebSocket 连接断	`proxy_read_timeout` 太短	WS 上游响应时长	`proxy_read_timeout` ≥ 心跳间隔
大文件上传 413	`client_max_body_size` 太小	看 error.log	调大 `client_max_body_size`
大文件上传 504	上游接收慢	—	`proxy_request_buffering off` + 调 timeout
HTTP/2 反代 `Connection reset`	协议版本	检查 `proxy_http_version`	必须设 `proxy_http_version 1.1`

常用命令速查

日志分析

# error.log 等级分布
tail -n 5000 /var/log/nginx/error.log | awk -F'[][]' '{print $4}' | sort | uniq -c | sort -rn

# access.log 状态码分布
tail -n 100000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn

# TOP 50 慢请求（需 $request_time 在日志格式中）
awk '{print $NF,$0}' /var/log/nginx/access.log | sort -rn | head -50

# 慢请求切片（$request_time > 1s）
awk -F'rt=' '{print $2}' /var/log/nginx/access.log | awk '{print $1}' | awk '$1 > 1 {print}' | sort -rn | head

进程与 FD

# 每个 worker 的 FD 用量
for pid in $(pgrep -f 'nginx: worker'); do
  fd=$(ls -1 /proc/$pid/fd 2>/dev/null | wc -l)
  echo "worker pid=$pid fd=$fd"
done

# TCP 连接统计
ss -s
ss -antp | grep ':80 ' | awk '{print $1}' | sort | uniq -c

上游探活

curl -sS -o /dev/null -w 'http_code=%{http_code} time_total=%{time_total}\n' --max-time 5 http://10.0.0.11:8080/healthz

# 模拟 Nginx 视角，强制 SNI（上游 HTTPS）
curl -v --resolve upstream.svc.local:443:10.0.0.11 https://upstream.svc.local/ -o /dev/null --max-time 5

Nginx 自身

nginx -V 2>&1 | head       # 编译参数（最重要）
nginx -t                    # 配置语法
nginx -T 2>/dev/null | less # 完整生效配置
nginx -s reload             # 平滑重载

TLS/SSL

# 证书有效期与域名匹配
openssl x509 -in /etc/nginx/ssl/app.example.com.crt -noout -issuer -subject -dates

# 完整握手测试
echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null | openssl x509 -noout -subject -dates -issuer

# OCSP stapling 状态
echo | openssl s_client -connect app.example.com:443 -status </dev/null 2>&1 | grep -E 'OCSP Response Status|OCSP Staple'

配置要点速览

完整配置模板和超时参数详解见 nginx-log-analysis-troubleshooting-guide。以下仅列本文方法论涉及的高频修复点。

upstream keepalive（防短连接打爆上游）

upstream backend {
    least_conn;
    server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
    keepalive 64;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

上游 HTTPS 反代（自签证书场景）

location / {
    proxy_pass https://backend_tls;
    proxy_ssl_server_name on;       # 强制 SNI
    proxy_ssl_verify off;           # 自签证书关校验
    proxy_ssl_session_reuse on;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}

WebSocket 反代

location /ws {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 300s;       # 必须 ≥ 心跳间隔
    proxy_buffering off;
}

gRPC/HTTP2 反代

server {
    listen 80 http2;               # H2C
    location / {
        proxy_pass http://127.0.0.1:50051;
        proxy_http_version 2.0;
        proxy_buffering off;
        proxy_request_buffering off;
    }
}
grpc_read_timeout 600s;            # 长请求必须放宽

大文件上传

client_max_body_size 100m;
client_body_timeout 60s;
location /upload {
    client_body_in_file_only on;   # 临时写盘，不堆内存
    proxy_request_buffering off;   # 边收边转
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
}

systemd 资源限制

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
LimitNOFILE=131072
LimitNPROC=65535

systemctl daemon-reload && systemctl restart nginx

实战案例

案例 1：登录页偶发 502 — keepalive 缺失

现象：5xx 比例突增到 5%，access.log 中 502 集中在 11:00-11:30。error.log 大量 upstream prematurely closed connection。每个 worker FD ~20K，接近上限。

排查：ss -antp | grep ':8080' | wc -l → 9500 连接。grep -A 5 upstream /etc/nginx/conf.d/backend.conf → 没有 keepalive。每个失败请求因 proxy_next_upstream 重试变成 2 个连接池占位。

修复：加上 keepalive 64;，reload 后 5xx 从 5% 降到 0.3%。

案例 2：客户端大量 499 — 上游慢但 Nginx 没切走

现象：access.log 中 499 比例 12%，后端 Java 无报错。awk -F'urt=' 提取 $upstream_response_time 发现大量 >1s，甚至 9.4s。

根因：上游某个接口慢，但 proxy_next_upstream 只匹配 error timeout，慢请求不触发重试，客户端等不住主动断开。

修复：

proxy_next_upstream error timeout http_502 http_503 http_504 non_idempotent;

上游侧增加熔断 + 慢请求告警。non_idempotent 让 POST/PUT 不再重试，减少重复提交。

案例 3：reload 后 worker 进程没换

现象：修改了 nginx.conf 新增 location，reload 后不生效。ps -ef | grep worker → worker 启动时间是 2 天前。

根因：用了 kill -HUP 而不是 nginx -s reload。某些发行版的 systemd unit 会截获 HUP 信号并忽略。

修复：systemctl reload nginx 或 /usr/sbin/nginx -s reload。修复后 worker 时间戳立刻刷新。

日志格式建议

所有排查的前提是 access.log 记录了关键字段：

log_format main '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                'rt=$request_time uct=$upstream_connect_time '
                'urt=$upstream_response_time ua=$upstream_addr '
                'req_id=$request_id';

$request_id（Nginx 1.11+）配合 proxy_set_header X-Request-ID $request_id; 可串联整个调用链。没有这些字段，排查效率降低 80%。

常见 FAQ

Q：改了配置 reload 没报错，但新配置不生效。 A：99% 是 include 顺序问题。conf.d/ 下按文件名字母序加载，后加载的覆盖前者。建议用数字前缀：10-backend.conf、20-static.conf。

Q：worker 进程被 SIGKILL（signal 9）杀掉。 A：被 OOM killer 杀掉。dmesg | grep -i oom + free -h 确认，必要时调低 worker_connections 或增加内存。

Q：access.log 看不到但磁盘空间在涨。 A：access_log 写权限丢失或被覆盖到别的路径。lsof | grep -E 'access.log|error.log' 定位。

Q：reload 时出现 recv() failed (104: Connection reset by peer)。 A：上游域名解析结果抖动。固定上游 IP 或配置 resolver + resolver_timeout。

Q：Nginx 启动慢、内存大涨。 A：通常是 geoip/map 大规则集或 limit_req_zone 太大。limit_req_zone $binary_remote_addr zone=one:10m; 对应 16 万 IP，再大考虑 Redis 共享存储。

TLS/SSL 握手故障附录

上游 HTTPS 反代场景中，TLS 握手失败是最容易被忽略的故障源。以下是完整排查路径。

握手排查四步

# 1. 看 Nginx 实际 OpenSSL 版本
nginx -V 2>&1 | tr ' ' '\n' | grep -i 'openssl\|boringssl'

# 2. 看证书有效期、域名匹配、签发者
openssl x509 -in /etc/nginx/ssl/app.example.com.crt -noout -issuer -subject -dates

# 3. 从 Nginx 主机模拟客户端握手
echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates -issuer

# 4. 检查证书链完整性
openssl s_client -connect app.example.com:443 -servername app.example.com -showcerts \
  </dev/null 2>/dev/null | grep -E 's:|i:'

常见 TLS 故障与修复

现象	error.log 关键字	原因	修复
握手间歇失败	`SSL_do_handshake() failed`	协议版本不匹配	`ssl_protocols TLSv1.2 TLSv1.3;`
上游 HTTPS 502	`SSL_CTX_use_PrivateKey`	证书私钥路径或格式错误	检查 crt/key 路径和权限
上游自签证书报错	`x509: certificate signed by unknown authority`	Nginx 验证上游证书	`proxy_ssl_verify off;` 或配置 `proxy_ssl_trusted_certificate`
SNI 不匹配	`no SNI provided`	上游 virtualhost 与请求域名不同	`proxy_ssl_server_name on;` + `proxy_ssl_name $host;`
OCSP stapling 无效	`ssl_stapling` 相关报错	DNS 不通 / 证书无 AIA / issuer chain 不全	见下方 OCSP 排查

OCSP Stapling 排查

# 检查证书有没有 OCSP responder URL（AIA）
openssl x509 -in /etc/nginx/ssl/app.example.com.crt -noout -text | grep -A 5 'Authority Information Access'

# 手动复测 stapling
echo | openssl s_client -connect app.example.com:443 -status </dev/null 2>&1 \
  | grep -E 'OCSP Response Status|OCSP Staple'

OCSP stapling 不生效的逐项排查：

OpenSSL ≥ 1.0.2（nginx -V 确认）
证书必须包含 AIA URL（签发时带上的 OCSP Responder 地址）
Nginx 必须能 DNS 解析 OCSP responder 域名 → resolver 必须配置
防火墙放行 80/443 出方向到 OCSP responder
ssl_trusted_certificate 必须是完整的 issuer chain

上游 HTTPS 反代完整配置

upstream backend_tls {
    server 10.0.0.11:8443;
    server 10.0.0.12:8443;
    keepalive 32;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/nginx/ssl/app.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/app.example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
    ssl_stapling        on;
    ssl_stapling_verify on;
    resolver            223.5.5.5 1.1.1.1 valid=300s ipv6=off;

    location / {
        proxy_pass https://backend_tls;
        proxy_ssl_server_name on;       # 把 SNI 转发到上游
        proxy_ssl_protocols   TLSv1.2 TLSv1.3;
        proxy_ssl_session_reuse on;
        proxy_ssl_name        $host;    # 用客户端 Host 作为 SNI 名
        proxy_ssl_verify      off;      # 自签证书关闭校验
        proxy_connect_timeout 5s;
        proxy_read_timeout    60s;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

内核参数陷阱与 FD 故障

下面几种报错现象不显眼，但新手最容易踩。

临时端口耗尽

ip_local_port_range 默认 32768 60999，可用端口约 28000。同时打到上游的连接数长时间超 28000 会端口分配失败。

sysctl net.ipv4.ip_local_port_range=1024 65000

短连接场景尤其要把范围拉大。每个 ephemeral 端口 60 秒内不可复用（tcp_fin_timeout 控制）。

FD 耗尽三重奏

报错	含义	排查
`Too many open files`	worker 进程 FD 耗尽	`cat /proc/<pid>/limits \\| grep 'open files'`
`accept: too many open files`	`accept()` 返回 `EMFILE`	同上，FD 已到 hard limit
`failed (24: Too many open files) while connecting to upstream`	上游连接也要占 FD	保证 worker FD ≥ `worker_connections` × 2

# 生产建议
# /etc/sysctl.d/99-nginx.conf
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
fs.file-max = 2097152

⚠️ tcp_tw_recycle 在 Linux 4.12+ 已废弃，且在 NAT 场景下曾导致诡异断连，不要再使用。

ulimit 与 systemd 双重作用

如果 systemd unit 写了 LimitNOFILE=100000，但 shell 层 ulimit -n 1024，master 启动后会采用 unit 设置的值。建议在配置模板里统一管两个值，避免不一致。

HTTP/2 反代陷阱

线上升级 HTTP/2 后常见"能连接但请求失败"的诡异现象。

核心规则：http2 与 proxy_http_version 1.1 必须同时配置。

server {
    listen 443 ssl http2;
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;    # HTTP/2 反代必须让上游走 1.1
        proxy_set_header Connection "";
    }
}

少了任意一行，上游直接报协议错误。客户端到 Nginx 是 HTTP/2（单 TCP 多 stream 复用），Nginx 到上游仍是 HTTP/1.1（stream 之间用 upstream keepalive 共享连接池）。上游响应慢 → 单 stream 卡住 → 客户端 HTTP/2 GOAWAY 关闭 → Nginx 处类似 RST。

监控告警最低配置

线上 Nginx 至少要有的告警项（结合业务基线调整阈值）：

groups:
  - name: nginx.rules
    rules:
      - alert: Nginx5xxHigh
        expr: |
          sum(rate(nginx_http_responses_total{code=~"5.."}[5m]))
          / sum(rate(nginx_http_responses_total[5m]))
          > 0.01
        for: 5m
        labels: { severity: warning }
        annotations:
          summary: "5xx 比例过高 {{ $labels.instance }}"

      - alert: NginxUpstreamDown
        expr: nginx_upstreams_up == 0
        for: 1m
        labels: { severity: critical }
        annotations:
          summary: "upstream 全部不可用 {{ $labels.instance }}"

      - alert: NginxConnectionsHigh
        expr: nginx_connections_active > 10000
        for: 5m
        labels: { severity: warning }
        annotations:
          summary: "活动连接数过高 {{ $labels.instance }}"

Prometheus 关键指标速查：

指标	用途
`nginx_http_responses_total`	按状态码分布，计算 5xx 比例
`nginx_connections_active`	当前活跃连接，接近上限即告警
`nginx_upstream_peer_connect_ms`	上游连接延迟
`nginx_upstream_peer_first_byte_ms`	上游首字节延迟（TTFB）
`nginx_connections_accepted/handled`	比值突降 → 连接被 RST，syn/accept 队列可能满了

日志侧建议用 Loki + Promtail 补充关键字告警：emerg/alert/crit 即时推送，error 5 分钟内超过 N 次自动告警。

关联页面

页面	关联点
nginx-log-analysis-troubleshooting-guide	参考手册：字段说明、超时参数、状态码表、完整案例、监控告警、性能调优
nginx-502-504-connection-reset-guide	502/504/Connection Reset 专项排查，含四段链路法
nginx-config-pitfalls	Nginx 典型配置错误复盘（proxy_pass 路径、keepalive、if 是邪恶等）
nginx-production-performance-optimization	生产级 Nginx 性能优化（OS 内核/Worker/HTTP I/O/Upstream）
nginx-pre-launch-checklist	上线前检查清单（超时参数等）
linux-kernel-tuning-production	net.core.somaxconn / fs.file-max 等内核参数调优
network-troubleshooting-order	基础网络连通性排障（防火墙/路由/tcpdump）
fullstack-performance-troubleshooting	全栈性能排障入口