云服务器端口标 1Gbps 只跑 30Mbps？三级限速与六条测速原则

上一篇讲的是流量的计费口径。这一篇讲另一个更容易被忽略、但直接决定实际体验的因素：端口速率标得很高，为什么到手用不出那个速度。市场上有 43.2 元标 10Gbps 的机器，也有 500 元标 500Mbps 的机器（独服），还有标 1Gbps 实际只跑 30Mbps 的。这些差别不在端口本身，在端口背后的三级限速。这篇把三级限速拆开讲，每一级配一个自查方法。

先放对照入口：

云途 —— 云主机与独服两条线的端口规格差异明显，适合对照。

spartanhost —— 10Gbps 端口产品，端口与配额的矛盾最典型。

isvoro —— 各档位端口从 100Mbps 到 1Gbps 不等。

rabisu、sixtynet、justg、zji、景文互联、数脉科技 —— 其他方向对照。

本文讨论端口速率限制的一般原理与通用测速方法，不针对任何具体商家，也不对任何产品作质量评价。文中给出的命令、阈值与示例均为通用参考，实际结果受虚拟化方案、宿主机负载、同机邻居行为、本地宽带与测试目标影响，同一台机器在不同时段、不同测试目标下的结果可能完全不同。端口标称值与保障带宽是两个概念，具体政策须以商家书面说明为准。

一、端口速率的限制分三级

还有一级常被漏掉但很常见：本地宽带。

如果你的上行只有 30Mbps，那测下载时最快也就 30Mbps——瓶颈在你家，不在服务器。

这个误判极常见。很多家用宽带上下行不对称，下行 500Mbps 但上行只有 30Mbps。

判断方法很简单：测下载（服务器发给你）和测上传（你发给服务器）对比。如果下载快上传慢，且上传恰好停在你家宽带的上行值附近，那瓶颈在本地，跟服务器无关。而这类「假故障」占了相当比例。

所以完整的排查顺序应该是四步：先排除本地宽带，再查网卡硬限，再查共享出口，最后查上游路径。

顺序很重要。因为本地宽带是最容易查的（换个网络对比即可），而其他三级都要在服务器侧排查。

换网络对比的方法：用手机流量测一次。

如果手机热点测出来的速率明显高于宽带，那问题在宽带。这一步花两分钟，能省掉后面很多排查。

还有一个容易被忽略的限制层：虚拟交换机的带宽配额。

有的平台在虚拟交换机层面给每台虚拟机设带宽上限，而这个值在虚拟机内部完全看不到。

表现是虚拟机内 ethtool 显示 10Gbps，但实测只能到某个固定值，且不随时段变化。

这种情况只能通过「多次测量数值稳定」来间接判断。

所以三级（或四级）的排查框架要记住一个原则：从最外层往最内层查，成本最低的先做。

本地宽带 → 上游路径 → 共享出口 → 网卡硬限。

这个顺序和「距离」相反，和「排查成本」一致。这也是排查任何网络问题的通用原则。

「标 1Gbps 只跑出 30Mbps」这个现象，可能是三级限制里的任何一级造成的。

层级	限制在哪	表现
第一级	虚拟机网卡限速	无论何时都跑不过这个数
第二级	宿主机出口共享	白天能跑满、晚上跑不满
第三级	机房上游出口	对特定目标慢，换目标就正常

这张表最该注意的是第一行：虚拟机网卡限速是最常见的，也是最容易被忽略的。

因为它不写在产品页上，但它是硬限制。你在虚拟网络里看到的「1Gbps 网卡」，可能被 tc 或虚拟交换机限到 100Mbps。

所以「端口 1Gbps」这句话，可能指的是「网卡是千兆」而不是「你能跑千兆」。这两个含义差十倍。判断方法很简单：如果无论什么时段、什么目标、测多少次都恰好跑在某个固定数字附近（比如 100Mbps 上下），那说明有硬限速。

第二行是共享出口。

宿主机给所有虚拟机分一条出口，标称是每台 1Gbps，但物理出口只有 1Gbps。十台机器一起跑，每台就只有 100Mbps。

这种限制的表现是有规律的：白天邻居闲着，能跑满；晚上邻居都在跑，跑不满。

第三行是机房上游。

机房整体的出口带宽有限，所有客户共享。这一级的表现是「对某些目标慢，对另一些目标正常」。

因为不同的目标走不同的上游路径。比如往国内慢、往日本快，说明问题在回国那段的上游。

三级的判断方法完全一样：换时段、换目标、换测试方式。

换个时段还慢 → 硬限速（第一级）。

晚高峰慢、白天正常 → 共享出口（第二级）。

换目标就正常 → 上游路径（第三级）。

三个判断能在一小时内做完。而它们的解决办法完全不同：第一级只能换产品，第二级可以加钱买保障，第三级只能换机房。

二、第一级：虚拟机网卡硬限

这一级还有一个识别特征：限速值通常是「整数」。

人工设置的限速很少会是 87Mbps 或 113Mbps 这种数字。

最常见的限速值是 10、20、30、50、100、200、500、1000 Mbps。

所以如果你的实测速率恰好停在 100.0 或 50.0 附近，而且多次测试都稳定，基本可以确定是硬限速。而共享型的速率一定是「不整的数字」——因为它是竞争的结果，不可能恰好落在整数上。这个特征比看 tc 规则更实用，因为虚拟机内部往往看不到限速规则。

还有一个混淆项：TCP 窗口和丢包导致的「假限速」。

在长距离链路上，如果 TCP 窗口太小，即使带宽很大也跑不满。

这个现象叫带宽延迟积限制。表现是「单线程慢，多线程快」。

判断方法：单线程和多线程（-P 4 或 -P 8）对比测。

如果多线程加起来明显超过单线程，说明是协议限制而非带宽限制。

这个区别很关键。前者可以通过调优解决（改窗口大小），后者只能换产品。

调优的方法：调整内核的 TCP 缓冲区参数。

# 看当前窗口设置
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

# 临时调大（需要 root）
sysctl -w net.ipv4.tcp_rmem="4096 87380 33554432"
sysctl -w net.ipv4.tcp_wmem="4096 65536 33554432"

判读要点：长距离高带宽链路上，缓冲区不够会直接限制吞吐。

这个调优的实际效果可能很明显。跨境链路上从 30Mbps 调到 80Mbps 是常见的。

但要注意这只在「带宽充足但跑不满」的情况下有效。如果带宽本身被限死了，调参没有用。

这一级最需要说清，因为它最隐蔽。

虚拟机的网卡速率通常由虚拟化层设定，而「网卡速率」和「实际可用带宽」是两件事。

很多平台的网卡标 1Gbps，但实际通过流量整形（tc）限到 100Mbps 或 200Mbps。

判断方法很明确：在同一天的不同时段测多次，如果每次都在同一数字附近（误差 5% 以内），基本可以确定是硬限速。因为共享型限速的结果一定是浮动的——邻居闲时快、忙时慢，不可能每次都恰好一样。

自查命令：看网卡本身的协商速率。

# 看网卡协商速率（虚拟网卡通常显示 10000 或 1000）
ethtool eth0 | grep -i speed

# 看是否有流量整形规则
tc qdisc show dev eth0
# 如果看到 tbf / htb / netem 规则，说明有限速

判读要点：网卡显示 10000Mb/s 但实测只有 100Mbps，说明限速在虚拟交换机或上层。

虚拟机内部看不到这种限制。这种情况下问商家是唯一办法。

再看一个实际的影响：硬盘速度也会伪装成带宽问题。

如果你测的是「下载文件」，而文件存在慢盘上，读盘速度会成为瓶颈。

典型表现：测速曲线上下跳动，且低于端口值。

判断方法：测上传（往服务器写）对比测下载。

如果上传能跑满、下载跑不满，瓶颈在磁盘读取。

这个误判很常见。很多人以为是带宽不够，实际是盘太慢。

还有一个：「端口 1Gbps」在独服和云主机上含义不同。

独服的 1Gbps 是物理网卡，通常真的能跑 1Gbps。

而云主机的 1Gbps 是虚拟端口，实际可用取决于虚拟化配置。

这个差别解释了为什么「独服端口不大但速度快」。独服标 30Mbps 是保证带宽，而云主机标 1Gbps 是端口上限。

两者不可比。一个是「承诺最小值」，一个是「理论上限」。

三、第二级：宿主机出口共享

这一级是共享型产品的固有问题，也是「晚高峰卡」的根源。

一台宿主机上跑着几十台虚拟机，它们共享一条物理出口。

而每台虚拟机都被标成「1Gbps」。这个标注从单机角度看没错，但从宿主机角度看是严重超卖的。

这个逻辑和 CPU 超售完全一样：只要大家不同时跑满，就没问题。而云主机上的绝大多数业务在绝大多数时间都不跑满，所以商家敢这么卖。问题只出在「所有人同时要用」的时候——晚高峰就是那个时刻。

怎么确认是这一级？看速率随时间的变化曲线。

# 连续记录一小时的上传速率，找出规律
for i in $(seq 1 60); do
  curl -o /dev/null -w "%{time_total} %{speed_download}\n" -s \
    http://测试地址/大文件
  sleep 60
done

判读要点：如果在固定时段（晚 8 点到 11 点）明显下降，其他时段正常，就是这一级。

这一级有一个特点：它不是「限制」，是「竞争」。

所以你无法通过投诉解决——商家的标注没有错。能做的只有两个：换时间跑，或者加钱买保障带宽。

还有一个变体：有的平台给每个虚拟机设「带宽配额」，但这个配额是动态的。

空闲时允许超出，忙时按配额分配。这种设计对正常业务友好，但让测速变得没有意义。

因为你测的时候可能正好是空闲时段，跑出来很快，实际业务高峰期就不行。

所以验收必须在业务高峰期测。这个原则比测多少次都重要。

再看一个相关的概念：「突发带宽」。

部分产品允许短时超过端口值（比如 1Gbps 端口允许突发到 2Gbps 几秒钟）。

这个设计对网页加载有帮助（页面是突发的），对持续传输没意义。

而测速工具恰好测的是短时峰值，所以会显示出「超过标称」的假象。

判断方法：跑十分钟以上的持续传输，看稳定值。

四、第三级：机房上游路径

这一级还有一个具体表现：丢包率随距离上升。

跨境链路的丢包率通常高于同城链路，因为中间经过的设备更多。

而丢包对吞吐的影响是超线性的——1% 丢包可能让吞吐掉 50%。

所以「上游路径差」经常不是带宽不够，是丢包让 TCP 无法跑满。这种情况下加带宽没有意义——带宽再大也会被丢包拖住。判断方法：看 MTR 的丢包率，如果从某一跳开始持续丢包，那就是路径质量问题，不是带宽问题。

丢包对吞吐的影响可以粗略估算：吞吐 ∝ 1 ÷ √丢包率。

所以丢包率从 0.1% 涨到 1%，吞吐大约掉到三分之一。

这个公式解释了为什么「感觉慢但测速不差」这种现象。

因为测速工具通常跑短时，丢包在短时内不容易显现。

而真实业务是长连接，丢包会持续累积影响。

还有一个上游相关的现象：「不对称带宽」。

有的机房对上行和下行给不同的容量。

比如下行 1Gbps、上行 100Mbps。

这个设计对下载站友好，对上传型业务（比如收文件、做备份节点）就不利。

验证方法：上传和下载分别测。如果两边差十倍，就是不对称的。

所以测速报告里必须写明「上行多少、下行多少」，只说一个数字没有意义。

这一点在自己的验收记录里要写清。否则后面无法对比。

这一级最容易被误判成「服务器慢」，实际问题在机房之外。

机房的出口带宽是有限的，而且通常分方向。

比如「回国方向 10Gbps、国际方向 100Gbps」。所以回国方向容易堵，国际方向不容易堵。

这个结构决定了「测速要选对目标」。用海外测速点测出来的数字，和用国内节点测出来的数字，可能差十倍。而用户实际访问走的是回国方向，所以真正该测的是回国方向的速率，不是国际方向的速率。

自查方法：对多个目标分别测速，看差异。

# 对三个不同地区的目标分别测速
# 国内目标
curl -o /dev/null -w "%{speed_download}\n" -s http://国内测速地址/文件
# 海外目标
curl -o /dev/null -w "%{speed_download}\n" -s http://海外测速地址/文件

# 或者用 iperf3 对不同节点测
iperf3 -c 国内节点IP -t 30
iperf3 -c 海外节点IP -t 30

判读要点：如果海外目标能跑满、国内目标跑不满，问题在回国上游。

这一级的解决办法只有两个。换机房，或者换有回国优化线路的产品。

因为上游路径不是商家能控制的（除非它买了专线）。

还有一个相关现象：「对某个特定 IP 慢」。

如果只有某一个目标慢，其他都正常，那可能是那个目标的服务器在限速，不是你这边的问题。

判断方法：换一个同地区的目标测一次。如果换了就正常，说明是对端问题。

这个误判很常见。很多人拿一个慢速的测试文件当基准，得出「我的机器带宽不行」的结论。

所以测速的基本原则是：至少三个目标、至少两个时段、至少两种方式。

单一测试的结论基本没有价值。因为影响因素太多。

五、大端口小配额的产品逻辑

这个逻辑还有一个变体：大端口 + 高价格。

同样的 10Gbps，有的卖 43 元，有的卖几百元。

差价的原因不在于端口本身，在于「端口能不能用满」。

43 元那款配额 2T，跑不满；几百元那款可能是真正的高带宽产品，配额也大。

所以「同样的端口，一个 43 元一个 500 元」这个现象，本质是两种产品挂了同一个端口数字。便宜的买的是「标称」，贵的买的是「可用」。判断方法还是算「满速能跑多久」——43 元那款 27 分钟，贵的那款可能是几十小时。

这个视角能解释很多「价格不合理」的困惑。

产品页上的端口数字是最好写的，也是最容易被拿来做营销的。

而真正决定体验的配额、保障带宽、共享比例，都不会写在显眼位置。

所以看产品页的正确顺序是：先看配额，再看端口，最后算「满速能跑多久」。

顺序反了就容易被端口数字吸引。

还有一个现象：端口越大的产品，越可能是共享的。

因为独占 10Gbps 的成本极高，而共享 10Gbps 的成本接近零（只要多数人不用）。

所以「10Gbps 端口」这个描述本身几乎不提供信息。

真正有信息量的是三句话：端口多少、独享还是共享、月配额多少。

三句话都答得上来的产品，才值得认真比价。

而只答其中一句的，基本可以按「营销数字」处理。

讲完三级限速，回头看一个产品设计问题：为什么有 43.2 元标 10Gbps 的机器。

答案很直接：因为它的流量配额只有 2T。

10Gbps 满速跑 2T 只需要 27 分钟。所以这个端口对它没有实际意义——用不到。

这就是「大端口小配额」的真相：端口是营销数字，配额是实际约束。商家给一个很大的端口，成本几乎为零（因为用不满），但产品页上「10Gbps」这个数字很有吸引力。所以判断这类产品，应该看「配额 ÷ 满速速率」得到的小时数，而不是看端口数字。

拿市场里的实际组合算几个例子，差距很明显：

500G 配 10Gbps = 0.4 小时（24 分钟）。

2T 配 10Gbps = 1.6 小时。

650G 配 1Gbps = 1.4 小时。

2T 配 1Gbps = 4.4 小时。

5T 配 2Gbps = 5.6 小时。

这些数字暴露了产品的真实定位。能撑不满一天的产品，都是「突发型」，不能做持续服务。

那什么产品能「持续跑」？配额要能支撑至少一周的满速运行。

按 1Gbps 算，一周满速是 75T。所以标 1Gbps 且配额 75T 以上的，才算是「能持续」的产品。

而这类产品在市场上很少。绝大多数的 1Gbps 标称，实际都是突发型。

这个判断能避免一个常见的错误：拿突发型产品做持续业务，然后怪产品不好。

产品没有问题。是定位理解错了。

反过来，独服的 30Mbps 端口是真正能持续跑的。

30Mbps 满速一个月是 9.7T，而独服通常不限流量。所以独服的 30Mbps 比云主机的 1Gbps 更有「持续」能力。

这个反差很适合用来理解「端口」这个词的双重含义。

云主机的端口是「上限」，独服的端口是「保障」。而营销数字永远只会写大的那个。

六、测速怎么测才有意义

六个原则，按重要性排。

第一：在业务高峰期测。这是最重要的一条，其他都可以妥协。

第二：至少三个目标，覆盖不同方向。国内、海外、同城各一个。

第三：持续十分钟以上，看稳定值不看峰值。

第四：上传和下载分开测。排除磁盘瓶颈。

第五：用大文件，不用小文件。小文件测的是延迟和 IOPS，不是带宽。

第六：多测几次，看波动。波动大说明是共享型。

六个原则里，第一条和第三条是最容易被忽略的。

因为大家习惯「装好就测一下」，而这一下的结果和真实体验关系不大。

下面是可直接跑的命令组合，三条覆盖下载、多流、上传：

# 1) 持续十分钟的下载测试，记录速率
curl -o /dev/null -w "速率: %{speed_download} 字节/秒\n耗时: %{time_total}s\n" \
  --max-time 600 http://目标/大文件

# 2) iperf3 多流测试（更能压满带宽）
iperf3 -c 目标IP -t 600 -P 4

# 3) 上传测试
iperf3 -c 目标IP -t 600 -P 4 -R

判读要点：看 iperf3 输出的最后几行「sender/receiver」稳定值，不看中间的峰值。

还有一个实用技巧：同时开两个测试，看总速率是否翻倍。

如果两个并发加起来等于单条速率，说明单条被限速了。

如果加起来翻倍，说明单条受对端限制。

这个技巧能快速区分「本机限速」和「对端限速」。很实用，而且不需要额外工具。

最后回到开头：标 1Gbps 只跑 30Mbps。

原因可能是网卡硬限、可能是共享出口、可能是上游路径，也可能是你自己的磁盘或本地宽带。 四种原因的表现不同，但都能通过「换时段、换目标、换方向」在半小时内定位。

而定位之后你会发现问题往往不在服务器上——这也是为什么「先测再问」比「直接投诉」有效。

本文讨论端口速率限制与测速方法的一般原理，不针对任何具体商家，也不对任何线路或产品作质量评价。文中给出的命令、判读阈值与换算公式均为通用技术参考；实际速率受虚拟化方案、宿主机负载、同机邻居行为、本地宽带条件、测试目标服务器状态与网络路径共同影响，同一台机器在不同时段、不同目标下可能得到完全不同的结果。端口标称值为端口规格，不等于保障带宽；是否独享、是否有硬限速、是否附带公平使用条款，均须以商家书面说明为准。文中所有换算结果（如「满速能跑多久」「持续跑需要多少配额」）为按理论满速计算的估算值，未考虑协议开销与实际损耗。本文全部内容不构成任何性能承诺或质量保证，亦不代表本站立场，也不代表对任何具体产品的推荐。选购前请自行实测验机，因实际速率不符合预期而产生的直接或间接损失，作者及本站不承担任何责任。