云服务器带宽跑满怎么办？

云服务器运行网站、文件下载、数据库同步或 Docker 应用时，有时会出现带宽持续占满的情况。

常见表现包括网站加载变慢、文件传输速度下降、SSH 操作延迟增加，以及网络请求超时。

但看到网络流量升高，并不能直接判断服务器遭到攻击，也不代表必须立即升级带宽。

建议先确认实际带宽限制和流量方向，再依次检查网卡、连接、进程及业务日志，找到主要流量来源后进行处理。

本文以 Linux 云服务器为例。命令中的网卡、目录、地址和进程编号，均需要根据实际环境修改。

一、带宽跑满和流量用完有什么区别？

带宽表示单位时间内能够传输的数据量，通常使用 Mbps，也就是兆比特每秒。

流量表示一段时间内累计传输了多少数据，通常使用 GB、TB 等单位。

例如，100Mbps 是传输速率，500GB 则是累计数据量，两者不能直接比较。

文件下载工具经常使用 MB/s 显示速度。按照十进制单位计算：

实际文件传输速度还会受到协议开销、线路、对端性能及磁盘读写等因素影响。

部分工具使用 MiB/s 等二进制单位，也需要注意区分。

带宽跑满不一定代表套餐流量已经用完，购买流量包也不等于提高带宽上限。

具体限制方式应以对应产品说明为准。

二、为什么带宽跑满会造成卡顿？

当业务持续发送的数据超过链路或限速策略能够处理的速度时，数据包可能排队等待。

排队时间增加，会导致网站请求、SSH 操作和其他交互的延迟升高。

当队列容量不足，或者限速策略直接丢弃超额数据包时，还可能出现丢包和重传。

因此，即使 CPU 和内存看起来正常，网络拥堵仍然可能导致服务器使用体验明显下降。

但短暂达到较高带宽，不一定属于故障。

应该结合持续时间、业务响应和实际限速方向判断。

入站和出站应分别观察，不要直接把两个方向相加后，与某一个方向的带宽上限比较。

三、先确认应该查看哪张网卡

不要默认所有服务器都使用 eth0。

首先执行：

ip -br addr

查看服务器网卡和 IP 地址。

再检查默认路由：

ip route show default

例如：

default via 192.0.2.1 dev eth0

这里的 dev eth0 表示这条默认路由使用 eth0。

如果实际显示的是 ens3、enp1s0 或其他名称，后面的命令应同步替换。

对于多网卡、VPN、网桥或策略路由环境，还需要结合具体业务路径判断，不能只看第一条默认路由。

另外，同一批数据可能经过物理网卡、网桥和容器虚拟网卡。

不要把这些接口的统计直接相加，否则可能重复计算。

四、使用 nload 查看网卡实时带宽

Debian、Ubuntu 可以安装本文使用的排查工具：

sudo apt update
sudo apt install -y nload iftop nethogs

Rocky Linux、AlmaLinux 等系统应先确认已配置的软件仓库是否提供这些工具，软件包可用性可能不同。

假设需要检查的网卡是 eth0，执行：

nload -u m eth0

其中，-u m 表示按 MBit/s 显示传输速率。

重点观察以下内容：

如果产品明确限制出站带宽，应主要观察 Outgoing。

建议在业务出现卡顿时持续观察几分钟，而不是只截取一次瞬时峰值。

不同工具的采样周期、单位换算和统计位置也可能存在差异。

按 q 或 Ctrl + C 可以退出。

五、使用 iftop 定位高流量连接

确认网卡流量较高以后，可以进一步查看数据主要与哪些地址通信。

执行：

sudo iftop -i eth0 -n -N -P

其中：

-i eth0 表示指定网卡。

-n 表示不进行主机名解析。

-N 表示不把端口转换为服务名称。

-P 表示显示端口。

界面会显示通信双方、传输方向，以及最近约 2 秒、10 秒、40 秒的平均速率。

=> 和 <= 表示两端之间的数据方向，阅读时应结合本机地址判断。

默认情况下，iftop 按 bit/s 显示速率。

如果使用 -B，则会改成 Byte/s，应注意单位变化。

例如，持续高流量的连接指向另一台服务器的 SSH 端口，可以继续检查是否存在备份、SFTP 或文件同步任务。

端口和地址只是线索，不能仅凭它们认定具体程序或判断是否违规。

按 q 可以退出。

六、使用 nethogs 查看哪个进程在传输数据

iftop 主要帮助定位通信地址和端口，nethogs 则可以辅助定位进程。

执行：

sudo nethogs -d 2 eth0

这里的 -d 2 表示每 2 秒刷新一次。

重点查看：

默认视图通常使用 KB/s，不是 Mbps，应以界面显示的单位为准。

找到需要检查的高流量进程后，例如 PID 为 2841，可以查看：

ps -p 2841 -o pid,user,etime,args

确认它的运行用户、持续时间和完整启动参数。

例如，高流量显示在 ssh 进程上，可能来自通过 SSH 传输的备份，而不一定是交互式登录本身。

部分 UDP、容器、转发或短生命周期流量不一定能准确归属到进程，应结合 iftop 和其他信息判断。

不要把 nethogs 没有显示完整的流量直接视为不存在，也不要看到高流量进程就立即强制结束。

七、使用 ss 核对连接对应的程序

可以继续查看 TCP 连接：

sudo ss -ntp

查看 UDP 套接字：

sudo ss -unp

查看 TCP 监听端口：

sudo ss -lntp

这些命令有助于核对本机端口、远端地址和对应进程。

例如，先在 iftop 中看到某个本机端口持续传输大量数据，再通过 ss 查找相关进程。

需要特别注意：

ss -ntp 展示的是连接及套接字信息，不会直接列出每个连接的实时带宽。

Recv-Q 和 Send-Q 也不是网速，不能把它们当作 Mbps 或 MB/s。

比较实用的组合是：

nload 看总体速率，iftop 找主要连接，nethogs 和 ss 辅助核对进程。

八、网站流量突然增大怎么排查？

如果主要流量来自 Nginx、Apache 或其他 Web 服务，可以继续查看对应网站的访问日志。

例如：

sudo tail -n 100 /var/log/nginx/access.log

以上只是常见路径。

使用宝塔或独立站点日志时，应查看该网站实际配置的日志文件。

重点检查问题发生时间附近，是否存在大量文件下载、图片请求、接口访问或重复请求。

不要只统计哪个 IP 请求次数最多。

一个请求可能下载几 GB 的文件，另一个请求可能只返回几百字节。

判断带宽来源时，还应结合响应大小、请求路径及持续时间。

如果网站经过 CDN 或 WAF，日志中的来源地址也可能是代理节点。

应先确认真实客户端 IP 的记录方式，再决定访问限制，避免误封正常代理节点。

九、Docker 容器造成高流量怎么检查？

执行：

docker stats --no-stream

可以辅助查看不同容器的资源和网络数据。

但其中的 NET I/O 表示已接收和发送的数据量，不是每秒传输速率。

因此，一个运行很久的容器显示累计传输几百 GB，并不能直接证明它现在占满带宽。

应间隔采样、观察增长情况，再结合网卡实时流量和应用日志判断。

查看具体容器日志：

docker logs --tail 100 容器名称

如果怀疑文件同步、照片上传、镜像拉取或下载服务造成流量增长，应先检查相应任务。

不要把所有 Docker 容器一起停止，也不要为了排查带宽直接清空 Docker 网络规则。

十、备份或文件同步占满带宽怎么办？

如果已经确认高流量来自正常备份，可以考虑调整执行时间、减少并发，或限制该任务的传输速度。

例如，通过 rsync 传输到独立备份服务器：

rsync -avP --bwlimit=2048 \
  -e 'ssh -p 22' \
  /data/backup/ \
  [email protected]:/srv/backup/

请把源目录、目标地址、账户、SSH 端口和目标目录替换成实际值。

这里的 --bwlimit=2048 在没有单位后缀时，表示约 2048KiB/s，也就是 2MiB/s，不是 2Mbps。

该参数限制的是这次 rsync 传输，不是整台服务器的总带宽。

实际网络占用还包含协议开销，也可能有短时波动。

已有备份任务运行时，应先确认能否正常中断和恢复，再安排限速任务。

不要直接修改不熟悉的生产备份流程。

十一、带宽跑满是不是被攻击了？

不一定。

正常的网站访问、文件下载、备份同步、图片分享和软件更新，都可能产生较高流量。

判断是否异常，需要结合业务情况、通信地址、访问日志、请求内容和进程行为。

如果发现来历不明的程序持续对外发送数据，应先保留进程、路径、连接和时间等信息，再进行限制和安全排查。

不要直接删除全部日志。

如果是大量入站流量已经挤占上游链路，单纯在服务器内部拦截数据包，未必能够释放到达服务器之前的带宽。

这种情况应向服务商提供现象和时间，确认产品的防护能力及可用处理方案，而不是只在本机不断增加封禁规则。

十二、带宽没跑满，为什么网络还是慢？

网络慢并不只有带宽不足这一种原因。

可以同时检查 CPU、内存、磁盘和应用响应。

查看进程和 CPU：

top

查看内存：

free -h

查看网卡统计：

ip -s link show dev eth0

重点观察 errors、dropped 等计数是否在故障期间继续增长。

这些属于累计统计，应比较前后变化，不能只看某个历史总数。

同时，虚拟机内部看到的网卡计数不能覆盖整条网络路径。

即使本机没有显示丢包，也不能排除上游限速或其他链路问题。

如果只有某个网站或接口慢，而其他服务正常，应继续检查对应程序、数据库、线路和目标服务，不要直接认定整台服务器带宽不足。

十三、业务已经受到影响，先做什么？

建议优先保留现场信息，再处理已经确认的流量来源。

可以先记录当前网卡收发速率、高流量连接、进程编号和问题时间。

然后通过应用自身的暂停、停止或限速功能，降低明确的下载和备份任务。

处理以后，再次观察带宽与业务响应是否恢复。

排查期间不要随意关闭网卡、清空防火墙、结束所有 SSH 进程或重启整台服务器。

如果远程连接已经非常卡顿，可以使用可用的控制台或 VNC 入口继续检查，避免失去管理通道。

十四、什么时候需要升级带宽？

如果已经排除异常程序和不必要的传输任务，并且正常业务高峰长期接近产品带宽上限，可以考虑升级带宽。

升级之前应确认：

高占用主要发生在哪个方向；

持续多长时间；

涉及哪些业务；

限制来自单台服务器、共享带宽还是目标线路。

对于可以缓存的公开静态资源，也可以评估缓存和 CDN。

对于大文件分发，可以评估独立存储或下载服务。

这些方案应根据业务选择，不能认为所有流量都适合缓存，也不能保证只升级带宽就能解决全部访问缓慢问题。

十五、带宽跑满快速排查表

推荐按照：

带宽规格 → 实际网卡 → 实时速率 → 高流量连接 → 对应进程 → 业务日志 → 限速或优化

的顺序排查。

十六、仍然无法判断怎么办？

如果带宽持续异常，并且无法确定来源，可以通过莱卡云客户中心提交工单。

建议提供服务器编号或 IP、产品带宽、问题发生时间及所用时区。

同时说明主要运行的业务、入站和出站情况，以及是否存在下载或备份任务。

可以提供以下信息：

ip -br addr

ip route show default

ip -s link show dev eth0

以及 nload、iftop 的相关截图。

如果只有特定地区或网络访问异常，也应说明测试网络和具体表现。

请隐藏密码、Token、带认证参数的完整命令及其他敏感内容。

不要将未经脱敏的业务日志或网络数据公开发布。

总结

云服务器带宽跑满时，应该先确认实际限制和流量方向，而不是立即重启服务器或认定遭到攻击。

使用：

nload -u m eth0

查看网卡实时速率。

使用：

sudo iftop -i eth0 -n -N -P

定位主要通信地址和端口。

再使用：

sudo nethogs -d 2 eth0

以及 ss、进程信息和业务日志，确认流量来自哪个程序。

找到原因后，再选择暂停非必要任务、调整并发、设置应用限速、优化业务或升级带宽。

先定位流量来源，再针对性处理，才能避免误停正常业务。