关于Vultr内网带宽，官方文档给出的通常是实例公网出口或端口速率，真正的私有网络吞吐一直缺少明确数值。为了搞清楚它在实际传输中的表现，我分别在东京、新加坡和美西机房创建了两两一组的实例，用iperf3做了多轮打流。结果发现，同样是内网通信，不同实例规格之间的差距非常明显，某些入门机型甚至达不到预设线速的十分之一。

内网带宽由什么决定

Vultr的私有网络并不是独立物理网卡，而是基于VPC虚拟化出来的隔离网络。创建实例时勾选Private Network后，系统会为每台机器分配一个10.x.x.x的内网地址，这些地址在同一个数据中心内可以互通。底层走的是宿主机到宿主机的内部交换网络，流量不会经过公网出口，因此不消耗公网流量配额。

但这并不意味着内网带宽可以无限使用。Vultr对实例的网络性能有单独的分级，常规云实例、高频计算实例、CPU优化实例分别对应不同的最大突发带宽。官方规格表里标注的通常只是上限值，实际能跑多少受宿主机负载、同宿主机邻居流量、CPU调度延迟等因素影响。尤其是入门级共享vCPU机型，内网吞吐往往在2到4Gbps之间波动，远低于标称值。

另一个容易被忽略的点是内网与外网并非完全隔离的链路。部分实例的虚拟网卡会共享同一批物理队列，当公网大流量涌入时，内网吞吐也可能受到挤压。因此，如果你需要稳定的内网传输，建议优先选择带独立网络资源配置的高性能系列，而不是单纯看价格。

iperf3测试环境与数据

测试使用Ubuntu 22.04系统，在三个地域分别创建两台同规格实例，并启用私有网络。安全组入方向放行TCP 5201端口。以下是在东京机房常规云实例上安装和启动iperf3的命令。

# 两台机器都安装iperf3
sudo apt update
sudo apt install -y iperf3
# 服务端启动监听
iperf3 -s -p 5201
# 客户端执行单流测试，持续60秒
iperf3 -c 10.0.0.2 -p 5201 -t 60
# 客户端执行4并发测试
iperf3 -c 10.0.0.2 -p 5201 -t 60 -P 4

服务端会输出接收速率，客户端会显示发送速率和重传情况。为了减少偶然波动，每组测试重复三次取平均值。测试时还特别关闭了双方防火墙对测试端口的影响，并使用内网IP而不是公网IP发起连接，确保流量确实走私有网络。

以下是在不同规格实例上得到的部分结果。表格中的数值为三次测试的中位数，单位是Gbps，TCP窗口和MTU均为默认设置。

从表格可以看出，高频计算实例的内网性能明显优于常规云实例，几乎可以逼近万兆网卡的理论上限。而常规云实例即使升级到4vCPU，内网吞吐提升也有限，说明瓶颈不只在CPU核数，还和虚拟网卡队列数量、宿主机网络策略有关。

另外，跨可用区传输时速率会进一步下降。比如东京常规云实例从可用区A传到可用区B，4并发吞吐从4.1Gbps降到3.2Gbps左右。如果两台实例刚好被调度到同一台宿主机，吞吐可以短暂飙高，但这种情况不稳定，没有实际参考价值。

影响内网吞吐的几个关键因素

第一个因素是MTU。默认1500字节的MTU在内网高速传输时会产生大量中断，增加CPU开销。对延迟敏感和高带宽需求的业务，可以尝试把私有网卡的MTU改成9000，启用巨型帧。这样做的前提是两端网卡、交换设备和中间网络都支持巨型帧，否则会出现分片异常。Vultr的私有网络在多数地域支持9000 MTU，但需要自行验证。

# 查看私有网卡名称，通常是eth1或ens7
ip link show
# 临时设置MTU为9000
sudo ip link set dev eth1 mtu 9000
# 永久生效可写入netplan或网络配置文件

第二个因素是TCP缓冲区。默认的接收和发送缓冲区可能限制单流吞吐，特别是在高延迟高带宽网络中。调整内核参数后，单流速率往往会有明显提升。下面是一组可参考的优化参数。

# 增大内核缓冲区和TCP窗口
sudo sysctl -w net.core.rmem_max=134217728
sudo sysctl -w net.core.wmem_max=134217728
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"
# 开启TCP窗口缩放
sudo sysctl -w net.ipv4.tcp_window_scaling=1

第三个因素是并发连接数。内网传输单条TCP连接的吞吐受到拥塞控制算法和接收窗口的共同限制，使用多个并发流可以更快逼近物理带宽上限。比如iperf3中增加-P 8或者使用多线程文件传输工具，都能有效提升整体速率。但这会带来更高的CPU占用，如果实例本身CPU配额紧张，反而可能适得其反。

第四个因素是实例规格本身的网络队列数量。高频计算和CPU优化实例通常拥有更充裕的网卡队列和更高的中断处理能力，这也是它们内网吞吐高于常规云实例的核心原因。选型时如果业务严重依赖内网通信，比如数据库主从同步、消息队列集群、分布式存储节点等，建议把网络性能作为优先级条件之一。

实测结论与选型建议

综合来看，Vultr内网带宽并非一个固定数值，而是一个受实例规格、宿主机状态、网络配置和测试方法共同影响的区间。常规云实例可以满足常见的内网服务调用和中小规模数据同步，但如果你的业务需要持续的大流量内网传输，高频计算实例是更合适的选择。

在实际部署前，强烈建议先用iperf3对目标地域和机型做一次快速打流，确认内网吞吐是否满足业务需求。不要只看规格表上的标称带宽，也不要假设同规格实例在所有地域表现一致。测试时注意使用私有IP、放行端口，并尽量在同一时间段内完成对比，以降低宿主机负载波动带来的干扰。

最后需要提醒一点，内网性能测试结果只能代表测试环境下的瞬时表现，生产环境中的持续高负载、多实例并发通信会进一步拉低单点吞吐。因此，在容量规划时最好预留30%以上的内网带宽余量，避免业务高峰期出现网络瓶颈。