关键卡点是连接队列积压、上游响应质量差及文件描述符耗尽：需检查listen backlog溢出、避免localhost解析延迟、启用upstream keepalive，并用tcpdump定位syn重传或fin延迟等链路异常。
排查 Nginx proxy_pass 转发效率低的网络瓶颈，关键不是看 CPU 占用率高低，而是聚焦连接建立、传输路径和系统资源限制这三个真实卡点。很多场景下 CPU 才 20%–30%，但请求却频繁超时或变慢，问题往往藏在底层网络与内核配置里。
查连接队列是否积压
Nginx 接收客户端连接依赖内核 listen 队列（backlog）。一旦队列满，新连接会被丢弃，表现为偶发 502 或首字节延迟高。
- 运行
ss -lnt，观察Recv-Q是否长期接近Send-Q（如0 511中 Recv-Q 持续为 500+） - 检查溢出次数：
nstat -az | grep ListenOverflows，数值持续增长说明队列已反复溢出 - 临时调大 backlog：在
listen 80 backlog=4096中显式设置，并同步调整内核参数net.core.somaxconn = 65535
验上游服务可达性与响应质量
转发慢常常不是 Nginx 的问题，而是后端响应慢、连接不稳定或 DNS 解析拖慢导致。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 避免用
localhost：Nginx 解析localhost可能触发 IPv6 回环查找失败再降级到 IPv4，产生数百毫秒延迟；统一改用127.0.0.1或具体 IP - 用
curl -w "@format.txt" -o /dev/null -s http://backend/health测试真实 RT，其中format.txt包含%{time_connect} %{time_starttransfer}等字段 - 确认后端端口通、防火墙放行、服务进程存活，且未因连接数限制拒绝新连接（如 Java 的 maxConnections）
看文件描述符与连接复用状态
反向代理中每个请求至少占用 2 个 fd（client + upstream），fd 耗尽会直接导致连接失败或排队。
- 查 Nginx worker 实际打开的 fd 数：
for pid in $(pgrep -f 'nginx: worker'); do echo "worker $pid: $(ls /proc/$pid/fd | wc -l)"; done - 比对
ulimit -n（进程级）、worker_rlimit_nofile（Nginx 配置级）和/proc/sys/fs/file-max（系统级），取最小值即为上限 - 启用连接池：upstream 块中加
keepalive 32;，并在 proxy_pass 前设置proxy_http_version 1.1;和proxy_set_header Connection '';
抓包定位链路异常环节
当怀疑是中间网络设备（如负载均衡器、防火墙、跨机房线路）引入延迟或丢包时，需跳过 Nginx 日志，直击 TCP 层。
- 在 Nginx 机器上抓包：
tcpdump -i any -s 0 port 80 or port 8080 -w nginx-proxy.pcap - 重点观察：SYN 重传（说明连接建不起来）、Server FIN 后长时间无响应（后端卡住）、大量 Dup ACK（丢包或乱序）
- 对比 client → Nginx 与 Nginx → upstream 两段的
tcp.analysis.initial_rtt，差异大说明后端链路质量差
