iPerf3 Tutorial: How to Use iPerf3 Step by Step
An iPerf3 tutorial for beginners: what iPerf3 is, how the client and server work, and how to run your first throughput test — no command line needed.
iPerf3 is the tool network engineers reach for when they need to know how fast a network link actually is. The problem for everyone else is that almost every iPerf3 guide drops you straight into a terminal, full of flags and IP addresses, with no explanation of what’s happening or why. This tutorial fixes that. It covers the whole thing — what iPerf3 is, the one concept you have to understand, and how to run your first real test — without assuming you live on the command line.
The short answer
iPerf3 measures the real throughput between two devices you control. You run it as a server on one device and a client on the other: the client sends traffic, the server receives it, and you read the speed off the client. In the iPerf3 Client & Server app you just flip a toggle between Client and Server mode — no commands — and the steps map exactly onto the iperf3 -s and iperf3 -c you’d otherwise type on a desktop.
What iPerf3 is (and what it measures)
iPerf3 is a free, open-source network testing tool. It measures throughput — how many megabits or gigabits per second a connection can actually carry — between two endpoints that you control.
That last part is the whole point. A regular internet speed test measures the path to your ISP; it can’t tell you anything about the link between your laptop and your NAS, or your phone and your access point, because that traffic never leaves your local network. iPerf3 tests the exact segment you point it at: Wi-Fi, Ethernet, a VPN tunnel, a 10 GbE trunk, whatever. If both ends are on your network, the result is your local speed, with the internet completely out of the picture.
The one concept that matters: client and server
iPerf3 always needs two roles, running on two different devices:
- The server opens a port (5201 by default) and waits, listening for a connection.
- The client connects to that server’s IP address, pushes traffic for a few seconds, and prints the result.
There’s no separate “server app” — the same iPerf3 does either role depending on which mode you pick. You decide which device is which based on what you want to measure to. If you want to know the speed to your NAS, the NAS (or a machine next to it) is the server. If you want the Wi-Fi speed in the far bedroom, put the server on a wired machine and carry the client there. Standing up the listener is covered in detail in how to run an iPerf3 server.
Your first test, step by step
The smallest possible test: a phone as the client, a computer as the server.
- Start the server. On the computer, open iPerf3 Client & Server, switch to Server mode, leave the port at 5201, and tap Start. Note the computer’s local IP (e.g.
192.168.1.20). - Connect the client. On the phone, stay in Client mode, enter that IP and port, choose TCP, and tap Start.
- Read the number. After a few seconds you get an average throughput in Mbps or Gbps. That’s the real speed of the link between the two devices.
That’s a complete test. The full walkthrough — picking endpoints, what’s a “normal” number for each link type, and how to isolate a slow result — is in how to test your LAN speed.
TCP or UDP: which to pick
iPerf3 can send two kinds of traffic, and they answer different questions:
- TCP answers “how much bandwidth?” It’s what you want 90% of the time — the headline speed number.
- UDP answers “how stable is the link?” It reports jitter (in milliseconds) and packet loss (as a percentage). Use it when you’re chasing choppy video calls or gaming lag, not raw speed.
Start with TCP. Reach for UDP only when bandwidth looks fine but something still feels wrong.
Reading the result
A test gives you a few numbers worth understanding:
- Average Mbps / Gbps — the effective throughput. The headline.
- Retransmits (TCP) — how many packets had to be resent. A few is normal; lots means a degraded link.
- Jitter and loss (UDP) — variation in timing and dropped packets. What you’d report to a network vendor.
If the number is far below what the link should do, the bottleneck is somewhere in the path — the radio, an access point, a cable, a switch, or the device on the other end.
The common iPerf3 commands (and the app equivalent)
If you ever do touch the CLI, these are the flags you’ll see most. The app exposes each one as a setting, so you don’t have to memorise them:
| Command | What it does | In the app |
|---|---|---|
iperf3 -s | Run as server (listen) | Server mode |
iperf3 -c <ip> | Run as client to that server | Client mode + server IP |
-p <port> | Use a different port | Port field |
-u | Send UDP instead of TCP | UDP toggle |
-P <n> | Run n parallel streams | Parallel streams setting |
-t <seconds> | Test for that many seconds | Duration setting |
-R | Reverse — server sends, client receives | Reverse / download toggle |
Because the wire protocol is identical to the standard iperf3 binary, a phone running the app is fully interoperable with the CLI on a laptop, a NAS, or a homelab box. The numbers mean the same thing everywhere.
What people actually use iPerf3 for
The same basic test answers a lot of real questions:
- Wi-Fi coverage and mesh: walk the house and test the speed at each node and room.
- LAN and NAS speed: confirm a gigabit or 10 GbE link delivers what it should.
- VPN overhead: measure real VPN throughput by testing with and without the tunnel.
- ISP problems: gather evidence of throttling that a Speedtest can’t show.
Why you don’t need the command line
The CLI works if you already live in a terminal. Most people don’t, and the command line can’t do the single most useful thing: run the test from the device that’s actually in your hand. A native iPerf3 app on iOS, iPadOS, macOS, and Android lets you stand at the spot you care about, run client or server mode with a toggle, save each result, compare sessions over time, and export to CSV or JSON when you need a record.
Bottom line
iPerf3 isn’t complicated once you have the one idea: it’s a client and a server measuring the real speed of the link between them. Pick which device is which, run the test, read the number. Do that and you can answer “is this connection actually fast?” for any segment of any network you own — no guessing, and no command line required.