监控nginx需区分端口监听与实时连接：用netstat -tlnp | grep nginx或ss -tlnp | grep nginx确认master进程监听状态；用ss -tn state established '( sport = :80 )' | wc -l统计established连接；启用stub_status模块可获取active connections及其reading/writing/waiting分布，三者之和即为真实并发连接数。
监控 Nginx 的 TCP 连接状态，核心是区分「端口监听」和「实时连接行为」两类信息：前者看它是否在正确地址和端口上等待请求，后者看当前有多少客户端连着、处于什么阶段（读头、发响应、空闲等待）。关键不在于堆工具，而在于理解每个指标的实际含义和局限。
查监听端口：确认 Nginx 是否已绑定并准备就绪
运行以下命令查看 Nginx 主进程监听的端口：
netstat -tlnp | grep nginx
常见输出如：
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1234/nginx: master
这表示 master 进程（PID 1234）在所有 IPv4 地址的 80 端口监听。注意：
- worker 进程不会单独出现在 LISTEN 行中，端口由 master 绑定后共享给 worker
- 若看到 127.0.0.1:80，说明只允许本地访问；[::]:80 表示 IPv6 监听
- 权限不足时可能看不到进程名，建议用 root 或 sudo 执行
- 现代系统更推荐用 ss -tlnp | grep nginx，速度更快、输出更清晰
看活跃连接：统计当前 ESTABLISHED 连接数
要了解此刻有多少客户端正在与 Nginx 通信（包括 Keep-Alive 空闲连接），执行：
netstat -tnp | grep ':80' | grep ESTABLISHED | wc -l
或更精准地只统计本机服务端口发起的连接：
ss -tn state established '( sport = :80 )' | wc -l
注意：
- 不要混淆“连接数”和“请求数”——一个 TCP 连接可承载多个 HTTP 请求（尤其开启 keepalive 时）
- 如果连接数长期接近 worker_connections 配置值，需检查是否配置过低或存在连接泄漏
- 大量短连接可能体现为 ESTABLISHED 数值波动剧烈；大量长连接则 Waiting 值偏高属正常
用 stub_status 获取连接状态分布
启用 ngx_http_stub_status_module 后，访问配置的 status 路径（如 /status），会返回类似：
Active connections: 152
server accepts handled requests
262648 262648 482932
Reading: 2 Writing: 8 Waiting: 142
其中关键字段含义：
- Active connections = Reading + Writing + Waiting，即所有未关闭的 TCP 连接
- Reading：正在读取请求头的连接，值大可能说明客户端发送慢或网络延迟高
- Writing：正向客户端发送响应的连接，值持续偏高可能后端响应慢或带宽受限
- Waiting：Keep-Alive 空闲连接，占 Active 大部分属健康状态，无需干预
该模块不提供全局连接池视图，但能帮你识别瓶颈趋势：比如 Writing 持续 > 10% 且 Waiting 下降，大概率是响应环节拖慢了连接释放。
结合日志与系统指标交叉验证
单靠连接数容易误判。建议同步关注：
- Nginx 错误日志中是否频繁出现 “accept() failed (24: Too many open files)” —— 表明系统文件描述符耗尽，影响新连接接入
- 用 ps aux | grep nginx 确认 worker 进程数量是否符合 worker_processes 配置
- 检查 ulimit -n 和 nginx.conf 中的 worker_rlimit_nofile 是否匹配，避免内核限制低于 Nginx 配置
- 若发现 ESTABLISHED 连接数远高于 stub_status 的 Active connections，可能是非 80/443 端口的连接（如健康检查、stream 模块 TCP 代理）干扰统计
