本页目录
“网络很慢”可能意味着吞吐量低、延迟高、抖动或丢包，原因可能在您的服务器上、在远端，也可能在两者之间的任何位置。下面的工具可以区分这些情况。请先安装它们。
Ubuntu 和 Debian（安装时如果询问是否将 iperf3 作为守护进程启动，请选择 No）：
apt install -y iperf3 mtr-tiny curlAlmaLinux 和 Rocky Linux
dnf install -y iperf3 mtr curl预期速度
端口速率是原始线路速率。以太网帧封装以及 IP 和 TCP 头部会占用其中一部分，因此在标准的 1500 字节 MTU 下，TCP 有效载荷速率最高约为端口速率的 94%：
| 端口 | 最大 TCP 有效吞吐量 | 按字节计 |
|---|---|---|
| 1 Gbps | ≈ 940 Mbit/s | ≈ 117 MB/s |
| 10 Gbps | ≈ 9.4 Gbit/s | ≈ 1.17 GB/s |
因此，在 1 Gbps 端口上测得 940 Mbit/s，说明链路已经跑满，而不是性能不足。能否以该速度到达特定目的地，还取决于远端服务器、其自身端口以及中间路径；而要达到 10 Gbps，通常需要多个并行流。DediJet 端口的带宽不限流量，因此测试不会产生额外费用（参见不限流量带宽详解）。配备 1 Gbps 端口的配置可升级至 10 Gbps，价格为
使用 iperf3 测量吞吐量
iperf3 可在您控制的两台机器之间测量原始的 TCP 或 UDP 吞吐量，不受硬盘或 Web 服务器的干扰。最理想的测试是在您自己的两台服务器之间进行：通过公网，或者在两台服务器位于同一机房时，通过可免费申请的私有 VLAN。
运行测试
在接收端服务器上开放端口，并启动一个只运行一次测试即退出的一次性服务端：
ufw allow 5201/tcp
iperf3 -s -1如果使用 firewalld，请使用 firewall-cmd --add-port=5201/tcp；不加 --permanent 的话，规则会在下次重新加载时消失。然后在另一台服务器上运行以下任一命令，每次运行前都需重新启动 iperf3 -s -1：
iperf3 -c 203.0.113.20 -t 30
iperf3 -c 203.0.113.20 -t 30 -R
iperf3 -c 203.0.113.20 -t 30 -P 4第一条命令从客户端向服务端发送数据，-R 会反转方向，-P 4 会运行四个并行流。测试完成后，使用 ufw delete allow 5201/tcp 删除防火墙规则。
解读结果
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-30.00 sec 3.28 GBytes 939 Mbits/sec 12 sender
[ 5] 0.00-30.04 sec 3.28 GBytes 938 Mbits/sec receiver以下示例输出显示了一条已跑满的 1 Gbps 链路。receiver 行表示实际到达的数据量。Retr 统计的是 TCP 重传次数：少量重传属于正常现象，成千上万次则说明路径上存在丢包或拥塞。
- 单个流慢、四个流快：说明存在单流限制，例如长距离传输时的 TCP 窗口。单个流所需的窗口大小为带宽 × 往返时间：1 Gbit/s × 150 ms ≈ 19 MB，超出了 Linux 默认设置所允许的范围。
- 只有单向速度快：对比加与不加
-R的测试结果。单向问题是提交工单时很有用的信息。 - 10 Gbps 测试：3.16 之前的 iperf3 版本会在单个 CPU 核心上运行所有流，这可能成为瓶颈。请使用
iperf3 --version检查版本，或使用-p在不同端口上启动多个 iperf3 进程。
虽然也有公共 iperf3 服务器，但它们是共享的，而且经常处于繁忙状态：其结果更多反映的是它们自身的负载，而不是您服务器的性能。如需测量 CPU、内存和磁盘而非网络性能，请参阅服务器性能测试。
使用 curl 测试真实下载
要测试真实的 HTTP 路径，请将大文件下载到 /dev/null（这样不涉及磁盘），并让 curl 报告各项数值：
curl -o /dev/null -s -w 'speed: %{speed_download} B/s ttfb: %{time_starttransfer}s total: %{time_total}s\n' https://mirror.example.com/large-file.iso请使用一台网络连接良好、靠近您所关注目的地的服务器上的大文件，例如从您所用发行版的镜像站列表中选取的 ISO 镜像。speed_download 的单位是字节/秒：117,000,000 B/s 约等于 940 Mbit/s。单次下载会受到远端服务器及其网络连接的限制，因此在得出结论之前，请对比多个下载源。添加 -4 或 -6 可对比 IPv4 和 IPv6；如果 IPv6 完全无法使用，请检查您的 IPv6 配置。
使用 ping 测量延迟和抖动
ping -c 100 -i 0.2 203.0.113.20100 packets transmitted, 100 received, 0% packet loss, time 19804ms
rtt min/avg/max/mdev = 11.204/11.391/12.877/0.214 msavg 是典型的往返时间，mdev（标准差）则是衡量抖动的实用指标。对于游戏服务器和语音应用，稳定的延迟比原始带宽更重要：应关注较低的 mdev 和 0% 的丢包率。我们延迟测试页面上的数据是根据距离计算的估算值，因此真实路由上的实测值可能有所不同。
定位故障点：mtr 与 traceroute
mtr 结合了 traceroute 和 ping：它会反复探测路径上的每一跳。请以报告模式运行，并设置足够的轮数，使结果具有参考意义：
mtr -rwbz -c 100 203.0.113.20-r 输出报告，-w 显示完整的主机名，-b 同时显示主机名和 IP 地址，-z 添加每一跳的 AS 号，-c 100 对每一跳发送 100 个探测包。
HOST: web1 Loss% Snt Last Avg Best Wrst StDev
1. AS64500 198.51.100.1 0.0% 100 0.4 0.5 0.3 1.9 0.2
2. AS64500 198.51.100.9 38.0% 100 1.3 4.9 1.0 48.2 9.1
3. AS64501 192.0.2.17 0.0% 100 7.9 8.1 7.8 9.4 0.2
4. AS64501 203.0.113.20 0.0% 100 8.3 8.4 8.1 10.2 0.3如何解读
- 只有延续到最后一跳的丢包才算数。第 2 跳显示 38% 的丢包，但第 3 跳和第 4 跳没有丢包：这说明该路由器对其自身生成的回复做了速率限制，这很常见，也无害。真正的丢包会从某一跳开始，并在其后的每一跳上持续出现，直到目的地。
- 延迟同理。如果某个中间跳出现延迟峰值，但没有延续到后续各跳，说明该路由器只是响应慢，而不是转发慢。
- 路由往往是不对称的。回程路径可能经过其他网络，因此从您服务器发起的 mtr 只能反映一半的情况。请同时从反方向运行一次。
- ICMP 被过滤？改用 TCP 探测某个开放端口：
mtr -rwbz -T -P 443 -c 100 example.com。
如果没有 mtr，traceroute -n 203.0.113.20（来自 traceroute 软件包）只会列出一遍各跳，而 tracepath 无需 root 权限，还能报告路径 MTU。
何时提交工单
请先查看网络状态页面。如果您发现丢包一直延续到目的地、两台网络连接良好的机器之间的吞吐量远低于上述数值，或者问题从某个特定时间开始出现，请通过技术支持提交工单。请附上：
- 服务器的 IP 地址，以及您测试时使用的远端地址。
- 双向的 mtr 报告：从您的服务器到目的地，以及从目的地或受影响的用户回到您的服务器，每个方向至少 100 轮。
- 您的 iperf3 或 curl 测试结果、测试时间（含时区），以及受影响的是 IPv4、IPv6 还是两者皆是。
- 问题是持续存在还是间歇出现，以及从何时开始。
网络中断按紧急问题处理，首次响应目标时间为 30 分钟；其他工单的首次响应目标时间为 4 小时。如果您怀疑遭受攻击，请先阅读 DDoS 防护。