压测数字难看？按这四层排查 Nginx 性能问题

第一层：连接建立阶段就卡住了吗

压测时如果看到大量连接超时、握手失败，问题多半出在连接建立阶段，而不是 Nginx 处理请求的能力。

先看两个数：当前系统打开的文件描述符数量和监听队列溢出计数。用 ss -s 看连接状态分布，用 netstat -s 看 listen overflows。溢出数一直涨，说明 somaxconn 或 tcp_max_syn_backlog 太小，新连接排队被丢掉了。

• ulimit -n 调到 65535 以上，并确认 Nginx 进程实际生效
• worker_rlimit_nofile 与系统限制保持一致
• somaxconn 和 tcp_max_syn_backlog 同步放大
• 检查是否有防火墙或安全组限制了并发连接数

连接都建不起来，后面几层就不用看了。

第二层：内核网络栈有没有拖后腿

连接能建立，但吞吐上不去，常见表现是 CPU 花在软中断上、TIME_WAIT 堆积。这时候看 sar -n DEV 和 netstat -an | grep TIME_WAIT | wc -l。

TIME_WAIT 过多通常出现在短连接场景，比如 Nginx 作为客户端去请求后端。开启 tcp_tw_reuse 能复用这些连接，但要注意它只对出站连接有效。tcp_fin_timeout 可以适当调小，加快回收。

另一个容易被忽略的是网卡多队列和中断绑定。单核处理网络中断，在万兆网卡上很容易成为瓶颈。用 ethtool -l 看队列数，必要时开启 RPS/RFS 让多核分担。

如果业务对网络稳定性要求高，机房线路本身的质量也很关键。面向美国用户的业务，选择线路稳定的机房能减少很多排查成本，比如 圣何塞独立服务器这类提供固定带宽的方案，网络表现相对可控。

第三层：反向代理和后端衔接顺不顺

Nginx 把请求转给后端时，每个请求都新建一次 TCP 连接的话，开销非常大。压测时观察后端服务器的连接数，如果远高于并发请求数，说明连接池没配好。

• upstream 里配置 keepalive，并设置合理的 keepalive_requests
• proxy_http_version 设为 1.1，否则 keepalive 不生效
• proxy_set_header Connection "" 清除客户端传来的 Connection 头
• proxy_connect_timeout、proxy_read_timeout 按后端实际响应时间设置，别照抄默认值

还有 proxy_buffering。开启后 Nginx 会先缓冲后端响应，客户端慢也不会拖住后端。但如果响应体很大，缓冲区要相应调大，或者干脆关掉走流式转发。

第四层：后端才是真凶的情况

前三层都排查完，Nginx 各项指标正常，但响应时间还是长，那就该看后端了。

常见情况：数据库慢查询、应用同步阻塞、缓存没命中。这时候在 Nginx 上再怎么调都是隔靴搔痒。用 upstream_response_time 日志字段确认后端耗时，再回到应用层定位。

把 Nginx 的 access log 格式加上 request_time 和 upstream_response_time，能快速区分是 Nginx 慢还是后端慢。这个习惯值得养成，排查效率会高很多。