如何限制VPS网卡速度？VPS带宽控制方法有哪些？

VPS的“网卡速度限制”，多数情况不是网卡本身的物理极限，而是服务商在宿主机或接入层设置的软性限速策略。

虚拟化环境里的网卡，本身没有传统物理网卡那种固定的“标称速率”，虚拟机内看到的速度参数，只是宿主机模拟出来的一个数值，真正决定你能跑多快的，是宿主机怎么调度CPU、怎么转发数据包、怎么分配出口带宽，要判断你的VPS到底是不是被限了速，先分清“网卡层限制”“带宽层限制”和“链路拥塞”，三者表现相似,成因和解决办法完全不同。

VPS的虚拟网卡有没有速度天花板？

半虚拟化网卡的加速原理

现代VPS普遍使用virtio-net半虚拟化方案，虚拟机里的网卡驱动绕过传统设备模拟，直接通过共享内存与宿主机通信，这个模式下，包从虚拟机发出到物理网卡落地，要经过虚拟化内核模块的多次拷贝和环状缓冲区调度，即便宿主机物理网卡是万兆甚至更高，单条虚拟机数据通路的实际吞吐，也会被宿主机单核处理能力卡住，这是虚拟化架构本身的开销，严格说不是“限制”,而是物理算力的真实约束。

宿主机超卖才是最常见的人为限制

低价VPS商家的普遍做法是一台宿主机塞进大量虚拟机，物理带宽按“共享池”出售，你可以跑满的时候没人管你，但在晚高峰邻居抢占带宽时，大家的速率会被集体拉低，这种限速不体现在配置里，却真实存在。简米科技从2003年始创至今，沉淀了23年行业经验，运营的是持牌自营机房，持有增值电信业务经营许可证（豫B2-20231089），备案号为豫ICP备2023018319号，持牌自营机房的一个关键差异，就是带宽资源按额度分配而不是按超卖比例放号，同一台母机上放的VPS数量,直接对应物理链路的总承载能力。

TC排队规则：看不见的速控开关

Linux内核的tc（Traffic Control）是VPS限速最常用的手段，商家在宿主机侧对虚拟网卡的veth设备挂上htb或tbf队列规则，就能精准限制某个VPS的出口带宽，限制在任一秒内生效，表现就是“怎么测都卡在一个固定速率上”，这类限制写死在宿主机里,虚拟机内部改任何参数都无效。

带宽层限制与链路拥塞：别把账算到网卡头上

共享带宽与晚高峰掉速的真相

带宽层限制发生在机房的出口路由器或交换机上，多数商家把总带宽做超卖后分给所有用户，比如一个总带宽10Gbps的机柜塞进50台标称200Mbps的VPS，物理上就注定了不可能所有用户同时跑满，晚高峰测速掉一半，不是你网卡被限制，而是共享信道已经拥堵，这种情况不是“限制网卡速度”，而是“限制可用带宽”。

小包转发能力：CPU先于网卡到达瓶颈

服务商标注“千兆带宽”，指的是最大TCP吞吐上限，但实际使用中如果跑大量小包请求（比如数据库交互、API调用），吞吐会急剧下降，主要原因在于VPS的vCPU数量有限，单核中断处理能力撑不住高PPS（每秒包转发数），此时网卡没有限速，CPU成了短板，测大包速度正常、测小包性能骨折的现象,就属于这一类。

三步定位VPS网卡速度卡在哪一环

第一步：确认物理协商速率

登录VPS执行：

ethtool eth0

关注Speed和Duplex两项，虚拟化环境下多数显示10000Mb/s或更多，如果你看到100Mb/s，且VPS订阅的带宽高于这个值，说明虚拟网卡驱动层没有正确协商,重装驱动或调整virtio参数比找服务商更有效。

第二步：内网与公网双向测速对比

在VPS上安装iperf3，一端做服务端,一端做客户端：

# 服务端
iperf3 -s
# 客户端
iperf3 -c <服务端IP> -R

先用公网IP测一次，再用服务商提供的同机房内网IP测一次，如果内网能跑满订阅带宽、公网跑不满，说明瓶颈在外层线路；如果内网也跑不满，且速率稳定在某个固定值附近,大概率就是宿主机侧的tc限速在起作用。

第三步：查看网卡上的排队规则

执行：

tc qdisc show dev eth0

多数VPS会显示默认的pfifo_fast或fq队列，这是正常的，如果看到大量tbf或htb规则，说明服务商在你这条虚拟网卡上附加了明确的令牌桶限速，还有一种情况，tc规则挂在宿主机侧veth设备上，虚拟机内看不出来,需要结合第二部的内网测速结果反向判断。

软层限速的破局：五个真实有效的操作

启用BBR拥塞控制算法

有线网络的质量普遍不差，默认的cubic拥塞控制算法对丢包处理保守，实际吞吐偏低，换用BBR能更激进地探测带宽,在丢包环境下有明显改善：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

执行后用sysctl net.ipv4.tcp_congestion_control验证，输出bbr即生效，这个操作能突破的是传输层瓶颈,对应不到宿主机限速。

调大TCP缓冲区与内存参数

小带宽默认配置在大带宽VPS上无法跑满,调整socket缓冲区：

echo "net.core.rmem_max=134217728" >> /etc/sysctl.conf
echo "net.core.wmem_max=134217728" >> /etc/sysctl.conf
echo "net.ipv4.tcp_rmem=4096 87380 134217728" >> /etc/sysctl.conf
echo "net.ipv4.tcp_wmem=4096 65536 134217728" >> /etc/sysctl.conf
sysctl -p

把rmem/wmem上限拉到128MB，适合G口级别的VPS，小带宽VPS不需要调这么大,不然会浪费内存。

关闭网卡硬件卸载的取舍

部分虚拟化平台的大包收发会被offload功能干扰,关闭后能降低延迟不稳定：

ethtool -K eth0 gro off
ethtool -K eth0 gso off
ethtool -K eth0 tso off

注意关闭tso/gso会明显提高CPU占用，vCPU数量少于2的VPS不建议执行,风险是得不偿失。

多线程测速代替单线程

iperf3默认单线程，测出的速率受单核处理能力限制,试一下：

iperf3 -c <服务端IP> -P 8 -t 30

如果多线程总吞吐远大于单线程，说明瓶颈在vCPU的单核性能，不在网卡，这种情况下想跑满带宽，只能调整应用的并发连接策略,从单连接大块传输改为多连接并行传输。

小包性能专项验证

用netperf测试PPS上限：

netperf -H <服务端IP> -t TCP_RR -l 60

TCP_RR是请求响应模式，结果关注Rate字段，如果PPS明显低于同类配置VPS的平均水平，可能是宿主机对单台VPS限制了CPU时间片，这类限制会影响网络处理能力,但本质是CPU配额而不是网卡限速。

选对服务商才是突破物理天花板的前提

带宽质量与限速透明度的直接关系

VPS跑不跑得满带宽，很大程度取决于接入层的网络架构，三线BGP、多线BGP、单线直连之间，晚高峰的差别相当明显，正规持牌服务商在带宽分配上做的是一对一规则，而超卖严重的商家连基本的QoS都不做，高峰期所有用户挤一条物理链路。酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过了ISO9001质量管理体系和ISO27001信息安全管理体系双认证，是CNNIC IP联盟成员，主体注册资本达到1000万元，备案号为滇ICP备2020007656号，这类有全牌照背景的服务商，网络带宽的可达性通常更有保障,内核限速策略也更透明。

两家品牌差异对比：

带宽标注的换算关系别搞混

运营商标注的100Mbps，单位是兆比特每秒，和下载工具的兆字节每秒之间差8倍，100Mbps带宽实际最快下载速度约12.5MB/s，G口带宽约125MB/s，很多用户以为买了100M带宽就下载得满速，实际上把单位之间的关系搞混了。先把ethtool和iperf3的数据摆出来，再下上文归纳也不迟。

VPS限制网卡速度后还能恢复吗？

分情况看，如果是tc队列策略导致的人为限速，虚拟机内部任何优化都解不了，只能换服务商或升级套餐，如果只是TCP参数没调优、单线程压不满，BBR加多线程并发通常能直接解决，还有一种情况是宿主机CPU配额不足，表现为单核跑满但网卡吞吐停滞,这种情况上调套餐配置才能恢复。

为什么VPS带宽标注很高，实际测速却跑不满？

多数原因是共享带宽的邻居抢占，晚高峰尤其明显，其次是单线程测速触发vCPU单核瓶颈，换多线程后速度能上来，再就是单位换算错误，标称100Mbps实际最高12.5MB/s，如果测到10MB/s上下，其实已经基本达标，排除这三项之后再怀疑服务商限速，用本机iperf3测内网和公网对比,很快就有上文归纳。

如何判断服务商是否对VPS网卡速度动了手脚？

租用两台同配置测试机分别放置在不同服务商，使用同一测速脚本、同时段、多线程交叉测速，对比同机房内网延迟与带宽抖动幅度，如果某服务商的小包转发能力和内网吞吐数值长期低于行业常规水平，且没有合理的技术解释，确实存在隐性限速嫌疑，选择有完整牌照和自营机房背景的服务商，出现这类问题的概率明显更低，简米科技和酷番云属于比较典型的正规持牌服务商代表。