Testing Real Network Speed with iPerf3

7 min read

If a transfer to or from your server feels slow, the first job is working out where it is slow. iPerf3 answers that. It measures the network path between your machine and one of our datacenters, with nothing else in the way.

This guide covers the six public iPerf3 servers at GoZen Host locations, the commands worth knowing, how to read the output, and the one mistake that makes a fast link look slow.

Why not the browser speed test link

The speed test on each st-*.gozen.host page is useful for a rough check, and it is the only option if you cannot install software. But it runs inside a browser tab, so the number it produces includes your browser’s own overhead, whatever else that browser is doing, and usually a single TCP connection.

On a short path that barely matters. On a long one it matters enormously, for reasons we measure below. iPerf3 removes the browser from the equation and lets you control the things that actually shape the result: direction, number of streams, and duration.

Install iPerf3 link

  sudo apt install iperf3
  

  sudo dnf install iperf3
  

  brew install iperf3
  

Any 3.x client works for the basic tests. --bidir needs 3.7 or newer. Version 3.16 was used for every measurement on this page.

The servers link

Each server handles one test at a time, so if someone else is mid-test yours waits a few seconds. Tests are capped server-side at 1 Gbit/s to protect other tenants on the node, which has consequences worth understanding before you start.

The download test link

This is the figure that matters when you are judging a host: how fast our server can push data to you. The -R flag reverses the direction so the server sends.

  iperf3 -c st-ams.gozen.host -p 5201 -R
  

Reading the output link

  [ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec   380 MBytes   159 Mbits/sec   12    sender
[  5]   0.00-20.00  sec   380 MBytes   159 Mbits/sec         receiver
  

Bitrate is the throughput. Transfer is how much data moved in the interval.

Sender and receiver are the two ends, and which is which depends on -R. With -R the server is the sender, so the receiver line is your download. Without -R the receiver line is what our server got from you, which is your upload. Read the wrong line and you will report the wrong direction.

Retr counts TCP retransmissions. What matters is the count relative to the data moved, not the raw number. A 60 second run that shifts 4 GB will show thousands of retransmissions at well under half a percent loss, which is healthy. Judge the rate, not the total.

One stream never tells the truth over distance link

This is the single biggest reason people conclude a distant datacenter is slow when it is not.

A single TCP connection can only have so much data in flight before it must wait for an acknowledgement to come back. The further away the server, the longer that wait, and the lower the ceiling on one connection. The relationship is roughly inverse: double the round-trip time and you halve what one stream can carry, no matter how much capacity the path actually has.

Here is that effect measured on 16 September 2026, from one of our own servers to our Singapore node, a 158.8 ms round trip:

Two streams carried exactly twice what one did, so the limit was the single connection, not the link.

Run the same test from further away and the pattern holds, shifted down. From a second machine on a longer path, 234 ms from Singapore:

Take the 159 Mbit/s that one stream managed at 158.8 ms and scale it for the longer round trip, and you would predict 108 Mbit/s. It measured 92. That is ordinary TCP doing what TCP does, and it is why the fix for a long path is more streams rather than a closer datacenter.

What happened to the 8-stream run link

It was stopped by our own bitrate cap. On the same path, eight streams climbed to 880 Mbit/s from the first machine and to 1130 Mbit/s from another of our machines, and in both cases the server’s 1 Gbit/s limiter aborted the test partway through with control socket has closed unexpectedly.

To complete a long-distance run rather than trip the limit, keep the total under a gigabit:

  iperf3 -c st-sgp.gozen.host -p 5201 -R -P 8 -b 110M -t 20
  

-b is applied per stream, so eight streams at 110M targets 880 Mbit/s in total. With -P, read the SUM line rather than the individual streams.

Distance is not the only thing that flattens a stream link

A laptop on WiFi tested the same Singapore server at 182 ms and managed 2.73 Mbit/s on one stream, far below what its latency alone predicts. The reason was in the retransmit column: 1.08% packet loss, roughly three times what the wired hosts showed. Loss punishes a single stream harder than distance does.

Eight streams took that same laptop to 28 Mbit/s, a tenfold gain from flags alone, but the real fix was a cable.

Other tests link

Upload, your machine to our server. Drop -R:

  iperf3 -c st-ams.gozen.host -p 5201
  

Both directions at once:

  iperf3 -c st-ams.gozen.host -p 5201 --bidir
  

UDP, for VoIP and game traffic, where jitter and loss matter more than raw speed:

  iperf3 -c st-ams.gozen.host -p 5201 -u -b 100M
  

Set -b at or below your own upload speed. Set it higher and the loss column will report packets that never left your machine.

Force IPv4 or IPv6. All six servers answer on both, and most clients prefer IPv6 when they have it:

  iperf3 -c st-ams.gozen.host -p 5201 -4
iperf3 -c st-ams.gozen.host -p 5201 -6
  

Troubleshooting link

Connection refused, or the client hangs link

Port 5201 is likely blocked by your firewall or your ISP. Check whether it opens at all:

  nc -zv st-ams.gozen.host 5201
  

“the server is busy running a test” link

Someone else is using it. Each server takes one client at a time. Wait a few seconds and try again.

“control socket has closed unexpectedly” link

You hit the 1 Gbit/s server cap, which is a result rather than an error. See above.

The number looks too low link

In rough order of how often it is the cause:

1. You are on WiFi. Check the retransmit column. Anything approaching 1% loss will dominate everything else. Use a cable.
2. You used one stream on a long path. Add -P 8. Expect several times the throughput.
3. The run was too short. A 5 second test on a 200 ms path spends most of its life ramping up. Use -t 20 or longer.
4. You forgot -R and are measuring your own upload.
5. Something else is using the line. Pause backups, sync clients, and streams.
6. Your own connection is the ceiling. No test can exceed what you pay for.

Related link

• Slow Website Performance for when the site is slow but the network is fine
• Diagnosing High Server Load for when the server itself is the bottleneck
• Datacenter Locations for the full list of where we run
• Our global network map with browser speed tests and live latency for every location