适用场景

Nginx 出问题通常不是它慢，而是配置里的默认值不适合当前负载（连接数、缓冲区、超时），或者上游有问题而 Nginx 只是「背锅」。排障要先分清是 Nginx 自身、上游还是客户端链路。

配置步骤（上游健康与超时配置）

# 1) 上游健康检查（开源版用被动判断 + 主动脚本，商业版用 health_check）
upstream app {
    server 172.16.1.21:8080 max_fails=3 fail_timeout=10s;
    server 172.16.1.22:8080 max_fails=3 fail_timeout=10s;
    keepalive 64;
}

# 2) 超时配置（按业务设，示例）
proxy_connect_timeout 3s;      # 连不上立刻失败，别拖
proxy_send_timeout 30s;
proxy_read_timeout 30s;        # 长任务接口单独放长
proxy_next_upstream error timeout http_502 http_504;

# 3) 日志里看上游耗时
log_format main '$remote_addr - $upstream_addr '
  '$request $status $body_bytes_sent '
  'rt=$request_time urt=$upstream_response_time urt_status=$upstream_status';

# 4) 归因判断
# request_time 大、upstream_response_time 小 -> 客户端链路慢
# upstream_response_time 大 -> 后端慢（查应用与数据库）

关键参数与建议

  • worker：worker_processes auto，worker_connections 按内存与并发评估
  • keepalive：到上游启用 keepalive 连接池，显著降低时延与端口消耗
  • 超时：client/upstream 读写超时按业务设，避免默认 60s 导致请求堆积
  • 缓冲：proxy_buffering 与 buffer 大小按响应体大小调，SSE/大文件要单独处理
  • HTTPS：会话缓存、协议版本、证书链完整；到期前自动续期并有告警
  • 限流与防护：limit_req/limit_conn 防突发，上传目录禁执行
  • 日志：访问日志含上游耗时（$upstream_response_time）便于定位
  • 诊断：nginx -T 看最终配置、stub_status 看连接状态、error_log 找线索

容易踩的坑

  • proxy_read_timeout 用默认 60s，后端 hang 住时请求大量堆积
  • 连接超时设成 60s，上游挂掉时用户要等一分钟
  • 没有 proxy_next_upstream，单实例故障即 502
  • 日志没记上游耗时，慢请求无法归因
  • 健康检查靠「看起来正常」，故障实例继续收流量
  • 长任务接口与普通接口共用超时，一刀切

验证与巡检

awk '{print $NF}' /var/log/nginx/access.log | tail -100    # 近似看上游耗时
nginx -T | grep -E 'proxy_connect_timeout|proxy_read_timeout|max_fails'

# 目标：上游超时配置与业务匹配、日志含 urt、故障实例 10s 内摘除
  • 巡检：超时配置有依据、日志含上游耗时、上游摘除记录、无 502/504 堆积

小结

Nginx 运维验收：能说清当前并发上限、上游连接是否复用、超时配置依据，并能用日志把慢请求归因到上游或自身。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。