适用场景

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

配置步骤（worker 与连接数调优）

# 1) 查看最终生效配置（比翻文件可靠）
nginx -T 2>/dev/null | grep -E 'worker_processes|worker_connections|keepalive' | head

# 2) 建议配置
# worker_processes auto;
# worker_rlimit_nofile 65535;
# events { worker_connections 10240; multi_accept on; use epoll; }

# 3) 连接数与文件句柄核算
# 上限 ≈ worker_processes × worker_connections
# 并发请求数 ≈ 上限 / 2（每个客户端占 1 个到客户端 + 1 个到上游）

# 4) 到上游启用 keepalive
# upstream backend { server 127.0.0.1:9000; keepalive 64; }
# proxy_http_version 1.1;
# proxy_set_header Connection "";

# 5) 运行状态
curl -s http://127.0.0.1/nginx_status

关键参数与建议

  • 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 找线索

容易踩的坑

  • worker_connections 用默认 512，高并发直接拒绝连接
  • 文件句柄（worker_rlimit_nofile）没同步调大，报 too many open files
  • 到上游没复用连接，TIME_WAIT 堆积，端口不够用
  • 多 worker 抢同一个上游连接，出现上游超时
  • 把 Nginx 的连接数与后端应用的连接池混为一谈
  • 改了配置不 nginx -t 直接 reload，服务起不来

验证与巡检

nginx -t
nginx -T | grep -E 'worker_connections|worker_rlimit_nofile'
curl -s http://127.0.0.1/nginx_status
ss -s | head -5

# 巡检：连接数水位 < 70%、TIME_WAIT 不异常增长、error_log 无 too many open files
  • 巡检：连接水位、句柄使用率、上游连接复用生效、配置语法检查通过

小结

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

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