Nginx 当前并发连接数应查内核级 ESTABLISHED 连接数，用 ss -s | grep "tcp:" 看 estab 值；宝塔显示的“当前请求数”仅为 HTTP 请求计数，不包含长连接、WebSocket 等真实并发连接。
怎么看 Nginx 当前并发连接数（不是请求数）
宝塔面板默认不直接展示「活跃 TCP 连接数」，它显示的“当前请求数”其实是 ngx_http_stub_status_module 统计的 HTTP 请求计数，和真实并发连接（尤其是长连接、WebSocket、慢请求）差距很大。真正影响服务器负载的是 ESTABLISHED 状态的 TCP 连接总数。
实操建议：
- 登录服务器终端，运行：
ss -s | grep "tcp:"
——看estab后面的数字，这是内核级真实并发连接数 - 查 Nginx 工作进程各自连接：执行
sudo ss -tnp | grep ':80\|:443' | grep 'ESTAB' | wc -l
，再结合ps aux | grep nginx看 worker 数量，判断是否某 worker 过载 - 宝塔里“网站监控”里的“并发数”字段不可信，它只统计 access.log 里每秒新进请求，漏掉 keepalive 和挂起连接
为什么 Nginx 并发高但 CPU/内存不高，网站却卡
典型症状是 ss -s 显示 estab 高达 2000+，但 top 里 nginx 进程 CPU 不到 10%，页面响应慢甚至超时。这往往不是性能瓶颈，而是连接被“堵住”了。
常见原因：
-
keepalive_timeout设得过大（如 65535 秒），大量空闲连接长期不释放，耗尽连接槽位 - 后端（PHP-FPM / Node.js）处理慢或阻塞，Nginx worker 被占满，新连接排队等待，
netstat -s | grep "listen overflows"可能出现非零值 - 客户端异常（如移动端弱网重试、爬虫未带
Connection: close），导致连接堆积在 TIME_WAIT 或 ESTABLISHED 状态 - 宝塔默认开启的“防 CC 攻击”若规则过松，可能放行大量低速慢连接（Slowloris 类攻击）
在宝塔里改 Nginx 并发相关参数要注意什么
宝塔修改 Nginx 配置本质是改 /www/server/nginx/conf/nginx.conf，但直接改全局配置风险大，推荐优先在网站配置中调整。关键是别只调 worker_connections，它只是单个 worker 最大连接数，实际限制还受系统级参数制约。
必须同步检查并调整：
- 确认系统最大文件描述符：
cat /proc/sys/fs/file-max
，如果低于 10 万，需在/etc/sysctl.conf加fs.file-max = 1048576并执行sysctl -p - Nginx 主配置里
worker_rlimit_nofile必须 ≥worker_connections，否则会报错open() "/dev/null" failed (24: Too many open files) - 每个网站的配置中，慎用
keepalive_timeout 65535；生产环境建议设为keepalive_timeout 15s，并配keepalive_requests 100防止单连接发起过多请求 - 宝塔界面修改后点“重载配置”，不代表生效——务必看右上角提示是否“成功”，并手动执行
nginx -t校验语法
怎么快速定位是哪个网站拖垮了 Nginx 并发
宝塔没提供按域名维度统计实时连接数的功能，得靠命令补位。核心思路：把连接按目标端口 + 源 IP + 域名反向代理头交叉分析。
实操步骤：
- 先看各端口连接分布：
sudo ss -tn sport = :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20找出连接最多的客户端 IP - 查该 IP 正在访问哪个网站：
sudo tail -n 10000 /www/wwwlogs/*.log | grep "1.2.3.4" | awk '{print $NF}' | sort | uniq -c | sort -nr（$NF是日志最后一列，通常是域名） - 如果用了反向代理，重点检查
proxy_set_header Host $host是否存在，否则日志里$host为空，无法归因 - 临时封禁可疑 IP：宝塔防火墙可加，但更准的是用
iptables -I INPUT -s 1.2.3.4 -j DROP，观察ss -s的estab是否明显下降
注意：ss 和 netstat 在高并发下本身有开销，别在流量高峰持续跑 watch -n1 'ss -s'，可能加重负载。排查完就停。
