宝塔面板实时连接数查看方法

应优先使用 ss 命令替代 netstat 查看宝塔面板的 TCP 连接：ss -tn state established '( dport = :80 or dport = :443 )' | wc -l 精确统计 80/443 端口已建立连接数，因其速度快、不丢连、直读内核。

怎么用 netstat 看当前所有 TCP 连接

宝塔面板本身不直接暴露实时连接数的监控入口，得靠命令行。最常用的是 netstat，但它默认显示所有协议、所有状态的连接，容易干扰判断。

实际要看「活跃的 HTTP/HTTPS 请求」，重点过滤 ESTABLISHED 和 TIME_WAIT 状态，且只盯 80/443 端口：

• netstat -ant | grep ':80\|:443' | grep 'ESTABLISHED\|TIME_WAIT' | wc -l —— 统计数量
• netstat -ant | grep ':80\|:443' | grep ESTABLISHED | head -20 —— 查看前 20 个真实活跃连接（含客户端 IP）
• 注意：netstat 在较新系统（如 CentOS 8+/Ubuntu 20.04+）可能被弃用，ss 更快更准，优先用下面这个

为什么推荐用 ss 替代 netstat

ss 是 netstat 的现代替代品，底层直接读取内核 socket 表，不走 /proc，速度快、开销低，尤其在高并发时差异明显——netstat 可能卡住或漏数，ss 基本不丢。

• ss -tn state established '( dport = :80 or dport = :443 )' | wc -l —— 精确统计 80/443 上的已建立连接
• ss -tn state time-wait '( dport = :80 or dport = :443 )' | wc -l —— 单独看 TIME_WAIT，排查端口耗尽风险
• 参数说明：-t TCP，-n 不解析域名（提速），state 指定连接状态，dport 是目标端口（即服务器监听端口）
• 别写成 sport（源端口），那会统计错——你关心的是连到你服务器的连接，不是你服务器往外连的

连接数突增时，怎么快速定位是哪个站点或 IP 在打爆

光看总数没用，得下钻。宝塔用 Nginx/Apache，真实请求 IP 可能被代理遮盖，所以不能只信 ss 显示的远端 IP——如果开了 CDN 或反向代理，它显示的是 CDN 节点 IP，不是真实用户 IP。

• 先用 ss 找出连接最多的 IP：ss -tn state established '( dport = :80 or dport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10
• 再查宝塔的 Nginx 日志：tail -n 1000 /www/wwwlogs/your-site-name.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -5 —— 这里 $1 是日志里的真实客户端 IP（前提是 Nginx 正确配置了 real_ip 指令）
• 如果日志里全是 127.0.0.1 或 CDN IP，说明 set_real_ip_from 没配，或者 CDN 头（如 X-Forwarded-For）没被信任——这时候命令行看到的 IP 和日志对不上，得先修 Nginx 配置

宝塔后台看不到连接数，但可以间接监控

宝塔「网站」→「设置」→「日志」里没有连接数图表，但「监控」页面里的「当前并发数」其实是 Nginx 的 Active connections，它等于 accepts - handled + requests 的某种推算值，和 ss 统计的 TCP 连接数不等价——前者是 Nginx worker 已接受但还没关闭的连接（含 keepalive），后者是内核层面所有 socket。

• 想长期观察趋势，别依赖宝塔界面，直接写个脚本定时跑 ss 并写入文件，比如每 5 秒记录一次：while true; do echo "$(date +%s),$(ss -tn state established '( dport = :80 or dport = :443 )' | wc -l)" >> /tmp/conn.log; sleep 5; done
• 注意：/tmp 可能被清理，生产环境建议写到 /www 下；同时别用 date +%F_%T，秒级时间戳（%s）更方便后续用 awk/gnuplot 处理
• 还有一点容易忽略：如果启用了 HTTP/2，一个 TCP 连接可能承载多个请求，此时连接数低但负载高——不能只盯着数字，要结合 CPU、带宽、Nginx 的 request per second 一起看