最准的并发连接数看 Active connections，它是Nginx应用层真实并发连接数，包含reading、writing、waiting状态，不依赖系统工具且不受TIME-WAIT/CLOSE_WAIT干扰；需启用stub_status模块并访问/nginx_status获取。
最准的并发连接数看 Active connections，不是进程数、不是日志行数、也不是 ps 统计的 worker 数——它只在 Nginx 自身状态页里实时暴露。
用 stub_status 模块直接看 Active connections
这是唯一能反映“当前正在处理的连接”真实值的方式，包含 keepalive 空闲连接和活跃请求连接总和。
- 确认模块已编译：
nginx -V 2>&1 | grep -o with-http_stub_status_module，没输出说明没装，得重编译或换包 - 在任意
server块里加配置（注意权限控制）：location /nginx_status {<br> stub_status on;<br> allow 127.0.0.1;<br> deny all;<br>} - 重载配置：
nginx -s reload，然后curl http://127.0.0.1/nginx_status - 输出第一行就是你要的：
Active connections: 1242—— 这个数字 =Reading+Writing+Waiting
注意：Waiting 是 keepalive 空闲连接，它占大头很正常；但若 Reading 或 Writing 长期卡高，说明后端响应慢或客户端发包慢，不是连接数问题，是处理瓶颈。
用 ss 快速估算 ESTABLISHED 连接数
当没法开 stub_status（比如权限受限、配置不允许），就退而求其次看 TCP 层的 ESTABLISHED 连接，它接近但略高于真实并发——因为含空闲 keepalive 连接，也含未完成 TLS 握手的连接（极少数）。
- 查 80 端口：
ss -ant | grep ':80\b' | grep ESTABLISHED | wc -l - 查 443 端口：
ss -ant | grep ':443\b' | grep ESTABLISHED | wc -l - 比
netstat更快更轻量，不依赖net-tools包，新系统默认可用 - 如果 Nginx 监听非标端口（如
listen 8001），必须把:80换成:8001，\b是防止误匹配:8080
这个值会比 stub_status 的 Active connections 略高 5%–15%，尤其在短连接多、keepalive 关闭时偏差更大。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
别踩这些坑：什么方法根本不能反映并发连接数
很多命令看似相关，实际统计的是完全不同的东西，误用会导致误判容量或掩盖真问题。
-
ps -ef | grep nginx | grep -v grep | wc -l—— 统计的是 worker 进程数，不是连接数。1 个 worker 能同时处理上千ESTABLISHED连接（epoll + 多路复用） -
tail -n 1000 access.log | wc -l—— 统计的是最近日志行数，是请求数（可能复用连接），不是连接数；且日志有延迟、可能被 buffer、还可能被 rotate 清空 -
netstat -antp | grep nginx | wc -l—— 匹配的是进程名，会混入LISTEN、TIME_WAIT、甚至其他端口连接，结果严重失真 - 只看
TIME_WAIT数量 —— 它是连接关闭后的残留状态，高 ≠ 并发高，而是短连接频繁或net.ipv4.tcp_fin_timeout设置过长
真正危险的信号是 CLOSE_WAIT 持续增长，说明 Nginx 或 upstream 没主动关连接，得查 keepalive_timeout、proxy_http_version 和后端超时设置。
实时观察波动比单次快照更有价值
并发是动态值，静态截图意义有限；持续观察才能识别毛刺、泄漏或周期性高峰。
- 用
watch -n 0.5 "curl -s http://127.0.0.1/nginx_status 2>/dev/null | head -1"每半秒刷一次Active connections - 或用
watch -n 1 "ss -ant | grep ':80\b' | grep ESTABLISHED | wc -l"对应 TCP 层 - 如果值在几十毫秒内剧烈跳变（比如 200 ↔ 1200），大概率是健康检查探针或爬虫扫端口，不是业务流量
- 长期缓慢爬升不回落，配合
CLOSE_WAIT增长，基本可判定连接泄漏，要翻 upstream 配置和应用层 close 行为
最后提醒一句：Active connections 是连接维度，不是请求维度；一个连接上可能有多个 HTTP/2 流或复用的 HTTP/1.1 请求——所以它永远小于等于你预估的 QPS，别拿它直接除以平均响应时间算吞吐。
