在搭建分布式服务、数据库主从复制或者容器集群时，实例之间的内网通信质量往往直接决定了整体架构的性能上限。Linode作为一款老牌云主机产品，其同机房内网的实际表现一直缺少系统的实测数据。本文通过在Linode同一机房内部署两台实例，围绕延迟、带宽和文件传输三个维度做了一轮完整测试，并把过程中的关键发现整理出来，供有类似选型需求的朋友参考。
测试环境与内网判定方法
本次测试选用Linode东京机房（Region为ap-tokyo），创建了两台Nanode 2GB规格的实例，系统均为Debian 12，内核版本6.1。两台实例在创建时特意选择了相同的可用区，这一点非常重要：Linode虽然不鼓励用户感知物理机位置，但从分配到的Host前缀可以看出实例大致落在同一组宿主机上，同Host前缀意味着大概率在同一个物理机架内，内网通信路径会更短。
判断两台机器之间是否走内网，最直接的办法是对比内网IP和公网IP的延迟差异。Linode给每台实例都分配一个内网地址（早期叫Private IP，现在统一并入VPC体系），在控制台的Networking页面可以看到。测试前先分别在两台机器上执行下面这段脚本，记录彼此的内网网卡地址：
# 查看内网网卡与地址 ip -4 addr show | grep eth1 # 记录对端内网IP，例如 192.168.140.15 PING_TARGET=192.168.140.15 ping -c 100 -i 0.2 $PING_TARGET
如果内网IP之间的延迟明显低于公网IP之间的延迟，且TTL值没有明显跳变，基本可以确认流量走的是机房内部交换网络，这部分流量不会计入公网出站配额。这一点对按流量计费的用户尤其重要，跨实例同步大量数据时走错通道，账单数字会很可观。
延迟与带宽实测数据
延迟测试使用ping发送100个包，间隔0.2秒。实测结果相当稳定：内网方向的平均延迟在0.35毫秒左右，最小值0.18毫秒，最大值0.62毫秒，抖动极小，几乎看不到毛刺。作为对比，走公网IP互ping的延迟在1.2毫秒到2.4毫秒之间波动。对于MySQL主从复制、Redis哨兵心跳这类对延迟敏感的场景，0.35毫秒的水平完全够用，基本可以让跨实例通信的开销忽略不计。
带宽测试使用iperf3，服务端监听5201端口，客户端发起10条流并行压测，持续30秒。命令如下：
# 服务端 iperf3 -s -p 5201 # 客户端，10并行流，30秒 iperf3 -c 192.168.140.15 -P 10 -t 30 -i 5
实测单条TCP流可以跑到约4.3Gbps，10条并行流合计稳定在9.6Gbps上下，基本贴着万兆网卡的物理上限。需要注意的是，Nanode这类入门规格的网络吞吐存在一定限制，换用Shared 8GB或Dedicated规格时，内网吞吐上限会有提升，但同规格下内网带宽始终显著高于公网带宽。另外iperf3的UDP模式测出来的极限值参考意义不大，同机房内网的重传机制几乎不触发，TCP实测结果更能反映真实使用体验。
补充一个小发现：将iperf3的测试方向反转后（原来的客户端做服务端），双向吞吐略有差异，大约有3%左右的偏差，推测与宿主机虚拟交换的队列调度有关，日常使用感知不到，但在做精细化容量规划时值得留意。
真实场景下的文件传输表现
基准工具的数据好看不代表实际业务表现好，因此又用scp和rsync做了两组文件传输对比。第一组是单个20GB的大文件，第二组是包含约12万个零碎小文件的目录。单大文件场景下，scp走内网的实际吞吐约1.1GB/s，传输20GB耗时约19秒，瓶颈已经从网络转移到了磁盘写入速度。小文件场景差距就拉开了：scp逐文件传输12万个小文件耗时接近8分钟，而rsync配合tar打包管道传输，同样数据只用了不到2分钟，命令如下：
# tar打包后通过内网传输，远端解包 tar -C /data -cf - small_files_dir | ssh root@192.168.140.15 "tar -C /data -xf -"
这个结果说明，同机房内网的网络能力已经强到磁盘IO和小文件元数据操作成为主要瓶颈。如果你在做实例间的数据迁移或备份同步，优先优化打包策略和文件系统性能，比纠结网络参数收益更大。此外建议把MTU保持默认1500，实测开启巨帧在Linode的虚拟网络栈上收益非常有限，反而容易因为配置不一致导致间歇性丢包。
总结与选型建议
整体来看，Linode同机房内网的表现属于同类产品中的主流偏上水平：亚毫秒级延迟、接近万兆的实际吞吐、稳定的低抖动，足以支撑数据库集群、消息队列副本同步这类对内网质量要求较高的架构。使用上有三点建议：第一，创建实例时尽量保证在同一Region，并通过内网IP互访，避免误走公网产生流量费用；第二，跨实例大量传数据时优先使用打包加管道的方式，规避小文件场景的性能陷阱；第三，如果内网吞吐达不到预期，先检查实例规格的网络限制，再排查安全组和防火墙规则，而不是盲目调整内核网络参数。
如果你的业务对跨可用区容灾有要求，则需要在同机房低延迟和跨机房高可用之间做权衡，跨可用区通信的延迟通常会上到2毫秒以上，这是另一套测试维度，有需要的话可以再做一轮对比。
Linode内网性能Linode评测内网延迟测试修改时间：2026-09-13 09:50:31