established连接数最反映真实并发负载，即当前活跃的tcp通道数，可用ss -nt | grep established | wc -l获取；它代表正在传输数据的连接，而非请求计数或进程数量。
直接看 ESTABLISHED 数量，它最接近真实并发连接数；别只盯着 ps 统计的进程数，那只是工作进程个数，不等于当前活跃连接。
查 TCP 连接状态分布（含 ESTABLISHED）
运行这条命令能一次性看到所有 TCP 状态及其数量：
netstat -n | awk '/^tcp/ {++state[$NF]} END {for (key in state) print key "\t" state[key]}'
重点关注输出里的 ESTABLISHED 行——它代表已建立、正在传输数据的连接，是衡量并发压力最直接的指标。
-
SYN_RECV过高说明有大量握手未完成，可能是 SYN Flood 攻击或后端响应慢 -
TIME_WAIT高通常正常（尤其短连接多的服务），但持续 >65535 可能影响新连接分配 -
CLOSE_WAIT持续增长是危险信号，大概率是 Apache/Nginx 未及时关闭客户端连接，需检查 keepalive 配置或后端超时
快速获取 ESTABLISHED 连接数（按端口过滤）
如果只关心 Web 服务（如 80/443 端口）的活跃连接，用这个更精准：
netstat -antp | grep ':80\b' | grep ESTABLISHED | wc -l
注意：grep ':80\b' 中的 \b 是单词边界，防止匹配到 :8080 或 :8000；若查 HTTPS，把 :80 换成 :443 即可。
- Apache 默认监听 80，Nginx 同理，但若改了监听端口（比如
listen 8001），必须同步调整grep的端口号 - 该命令依赖
netstat，在较新系统（如 CentOS 8+/Ubuntu 20.04+）可能需先安装net-tools包 - 若服务用非 root 用户运行，
netstat -antp中的-p（显示进程名）可能因权限不足而空白，但不影响计数
对比看：Nginx/Apache 工作进程数 ≠ 并发连接数
这类命令只告诉你开了几个 worker 进程，不是当前处理多少请求：
ps -ef | grep nginx | grep -v grep | wc -l
ps -ef | grep httpd | grep -v grep | wc -l
Nginx 的 worker_processes 和 Apache 的 MaxRequestWorkers 决定的是最大并发能力上限，实际连接数由请求到达节奏、keepalive 设置、后端响应时间共同决定。
- Nginx 默认开启
keepalive_timeout 65，一个连接可复用多次，所以 4 个 worker 进程轻松支撑上千ESTABLISHED - Apache prefork 模式下，每个进程只处理 1 个请求，此时
httpd进程数才更接近并发请求数；但 worker/event 模式就完全不同 - 用
watch -n 1 "netstat -antp | grep ':80' | grep ESTABLISHED | wc -l"实时观察波动，比静态快照更有参考价值
替代方案：ss 命令更轻量、更可靠
netstat 正逐步被 ss（socket statistics）取代，尤其在高并发场景下性能更好、结果更准：
ss -ant | awk '$1 ~ /tcp/ && $NF ~ /ESTAB/ {++s} END {print s+0}'
或者按端口筛选：
ss -ant 'sport == :80' | grep ESTAB | wc -l
-
ss不依赖网络协议栈的 proc 接口，不受内核模块加载影响，netstat在某些容器环境里甚至根本跑不动 -
ss -ant输出字段顺序固定，$NF稳定指向状态列；而netstat -n在不同系统上列数可能浮动，导致awk脚本出错 - 如果提示
command not found: ss，CentOS/RHEL 系统执行yum install iproute，Debian/Ubuntu 执行apt install iproute2
真正要盯住的从来不是“有多少进程”，而是“有多少 ESTABLISHED 连接正在等响应”——这个数字一旦逼近你配置的 worker_connections 或 MaxRequestWorkers，服务就开始排队或拒绝新请求。TIME_WAIT 和 CLOSE_WAIT 的异常堆积，往往比 ESTABLISHED 高更值得连夜排查。
