带宽跑满不代表带宽不够，大量并发连接把连接表、防火墙会话或应用线程占满，业务照样卡，排查重点要放在并发连接数和连接状态上。
带宽跑满业务卡顿怎么查并发连接
很多运维看到带宽监控跑到95%以上，第一反应是扩容，但扩完带宽发现业务还是卡，登录服务器一看，CPU和内存都不高，流量也在跑，这种情况多数不是带宽吞吐不够，而是并发连接数触顶。
先分清两个指标：带宽吞吐和并发连接
- 带宽吞吐看的是每秒传输多少Mbps,瓶颈通常在网卡、交换机端口或运营商限速。
- 并发连接数看的是同一时刻建立并保持的TCP/UDP会话数量，瓶颈在操作系统连接跟踪表、防火墙会话表或应用线程池。
用一个表格对比更直观：
| 对比项 | 带宽吞吐 | 并发连接数 |
|---|---|---|
| 单位 | Mbps/Gbps | 个 |
| 占满表现 | 网卡流量图持续打满 | 连接表计数接近上限 |
| 业务卡顿 | 大文件下载慢、视频缓冲 | 新连接建立慢、网页转圈 |
| 常见瓶颈 | 物理链路、限速策略 | conntrack表、应用线程 |
查并发连接数先看三个入口
- 系统层：
ss -s直接给出TCP连接总数和状态分布。 - 内核层：
cat /proc/sys/net/netfilter/nf_conntrack_count查看连接跟踪表当前条目数。 - 应用层：Nginx、MySQL、Redis各自有活跃连接统计，
nginx -T查看worker连接配置，或SHOW STATUS LIKE 'Threads_connected'查看MySQL当前连接。
服务器带宽占满但网页打开慢是什么原因
服务器带宽占满但网页打开慢,多数人误以为是带宽不够，其实网页打开慢往往不是持续大流量，而是连接建立慢，一个小网页才几百KB，带宽完全够，但请求排队等连接资源，就会表现为转圈。
带宽阻塞和并发连接耗尽的典型区别
- 带宽阻塞：下载速度稳定变慢，ping延迟升高但丢包不明显，流量图是平滑曲线。
- 并发耗尽：流量图有毛刺，ping可能正常，但新TCP握手没响应，已有连接还能传数据。
用一条命令快速判断
在Linux服务器执行：
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn如果看到大量 SYN-RECV 或 TIME-WAIT，说明连接建立或回收有问题；ESTAB 数量接近内核上限，就是并发连接触顶。
Linux服务器怎么查看并发连接数
Linux服务器怎么查看并发连接数,这是运维排查卡顿的基本功，不同发行版命令略有差异，但核心思路一致：先看总量，再看状态分布，最后定位来源IP。
常用命令拆解
ss -s：输出Total、TCP、UDP等统计，一眼看总量。ss -tan state established | wc -l：统计当前已建立的TCP连接数。ss -tan state time-wait | wc -l：统计等待回收的连接数。netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c | sort -rn：老版本系统用这个看状态分布。
查看连接数上限
执行：
cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
cat /proc/sys/net/core/somaxconn前两个分别表示连接跟踪表最大条目数和半连接队列长度,第三个是应用层accept队列上限，行业共识认为，连接数触顶时先检查 nf_conntrack_count 是否接近 nf_conntrack_max，如果接近，就需要清理或调大。
按来源IP定位连接大户
真实场景中,一台Nginx服务器突然卡顿，带宽跑了不到一半，但
ss -s 显示TCP连接数比平时翻了数倍，执行：
ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head很快能看到某个IP或某个网段占了大量连接,很多时候是合作方的爬虫没限速，或者内部监控脚本反复建连不释放。
企业专线价格与并发连接数有关吗
企业专线价格与并发连接数有关吗？直接说结论：企业专线价格主要跟带宽、线路质量和SLA有关，但承载并发连接的能力受设备性能和会话表大小影响，这部分会反映在整体网络方案成本里。
低价宽带和高并发场景的冲突
- 普通家宽或低价云主机通常限制并发会话数,跑大量小包连接时容易丢包。
- 企业专线带宽可能只有50M,但会话表可以到几十万，适合门店、IoT设备、API网关等场景。
- 如果业务是长连接密集类型,不能只看每Mbps单价，要问清单机或单线路的并发连接上限。
北京机房带宽跑满业务卡顿排查步骤
以北京机房服务器为例,带宽跑满又卡顿时按下面顺序查：
- 登录服务器,先跑
ss -s看TCP连接总量有没有异常升高。 - 跑
sar -n DEV 1 10看网卡吞吐曲线，确认是持续打满还是瞬时尖峰。 - 执行
ss -tan state syn-recv | wc -l查半连接数，判断是否被SYN Flood或应用响应慢拖住。 - 查看
dmesg | tail -20有没有nf_conntrack: table full报错，这是最直接的证据。 - 按来源IP聚合：
ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head找出占用连接最多的客户端。
并发连接数过高怎么解决
定位到并发连接数过高后,不要急着加内存或升配置，先做连接治理。
先从连接复用和超时入手
- 缩短
TIME_WAIT回收时间，开启net.ipv4.tcp_tw_reuse
和调整
tcp_fin_timeout。 - 应用层开启HTTP keep-alive复用，减少频繁建连。
- 检查Nginx的
worker_connections和keepalive_timeout，避免默认值过小或过大。
再考虑限制单IP连接数
- 用
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j REJECT限制单IP并发。 - Nginx可以配置
limit_conn模块，按IP限制同时处理连接。 - 如果是正常业务增长,调大
nf_conntrack_max和somaxconn，但同步评估内存占用，因为每条连接跟踪都消耗内存。
业内专家指出,多数带宽跑满业务卡顿的案例，根因不是带宽本身，而是连接态管理失控。
带宽跑满并发连接常见问题
带宽跑满业务卡顿一定要加带宽吗？
不一定,先查并发连接数和连接状态分布，如果流量图有大量毛刺、连接表计数接近上限，加带宽只是浪费钱，优先做连接治理、限制单IP、优化超时参数，多数情况下就能把业务恢复平稳。
怎么判断是带宽不足还是并发连接数耗尽？
看两个指标：网卡吞吐曲线是否持续接近物理上限，以及 ss -s 或conntrack计数是否触顶，带宽不足时下载类流量稳定占满，并发耗尽时新建连接失败或超时，已有连接还能传输。
服务器并发连接数多少算高？
没有固定数值,取决于内核参数、内存大小和业务类型，一台8GB内存的云服务器，默认conntrack_max通常在几十万级别，但业务模型是长连接、小报文时，几万连接也可能拖垮应用，Linux内核会根据内存自动计算nf_conntrack_max，具体可以用 sysctl net.netfilter.nf_conntrack_max 查看。
排查带宽跑满业务卡顿，先看连接数再看带宽，把TIME_WAIT、半连接和来源IP分布查清楚，大多数情况不需要盲目扩容带宽。