最直接有效的办法是执行 ss -tn state established | wc -l，它返回当前真正处于通信状态的 TCP 连接数，最贴近业务并发压力；ss 比 netstat 更高效且原生支持内核级状态过滤，避免字符串匹配误判，查特定端口需用 sport/dport 并加单引号，监控时建议 watch -d -n 2 间隔采样，但该值仅反映 TCP 建链数，不等同应用层实际负载。
最直接有效的办法是执行
，它返回的是当前真正处于通信状态的 TCP 连接数，也是最贴近业务并发压力的指标。别用
—— 新系统（CentOS 8+、Ubuntu 20.04+）默认没装，硬装纯属多此一举。
为什么
比
更可靠
内核级状态过滤，不依赖字符串匹配，避免误命中日志、注释或端口名里带 “ESTAB” 的干扰项；
是
原生语法，比管道加
快 2–3 倍，尤其在万级连接时差异明显；
也合法（
是缩写），但语义不如
清晰，建议写全。
查特定端口的已建立连接数（如 Nginx 的 80 端口）
服务端监听并已建立的连接（即客户端连上来了）：
客户端连出去的目标是 80 端口（比如反向代理上游）：
Docker Desktop（linux）
当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。
下载
注意点：
单引号必须保留，否则 shell 会把
或
当作特殊字符解析
指本机源端口（服务监听端口），
指目标端口（客户端连谁）
若系统内核太老（如 RHEL 6），
不支持
，退化为：
实时监控连接数变化时容易卡死或不准
高频轮询会加重网络栈负担，尤其在高并发场景下：
用
，间隔至少 2 秒
加
参数可高亮数值变动：
绝对不要用
或
频繁刷 ——
调用本身有开销，每秒一次已足够捕捉趋势
如果发现数值波动剧烈但业务无异常，先确认是否含长连接复用（HTTP/1.1 keepalive、gRPC、DB 连接池），此时
数 ≠ 实际 QPS
真正容易被忽略的是：这个数字只反映 TCP 层“已建链”，不体现应用层是否真在处理请求。比如一个 Nginx 连接可能空闲等待数据，一个 MySQL 连接可能卡在慢查询里。要看真实负载，得结合
、
或应用日志里的 request duration 才行。
ss -tn state established | wc -lnetstatss -tn state establishedgrep ESTABLISHEDstate establishedssgrepss -tn state estestestablishedss -tn 'sport == :80' state established | wc -lss -tn 'dport == :80' state established | wc -l:==sportdportsssport/dportss -tn | awk '$5 ~ /:80$/ && $NF ~ /^ESTAB/' | wc -lwatch -n 2 'ss -tn state established | wc -l'-dwatch -d -n 2 'ss -tn state established | wc -l'-n 0.5-n 1ssESTABLISHEDnginx stub_statusshow status like 'Threads_connected'