iPerf3 on iPhone and Android: A Guide to Mobile Network Testing

For two decades, iPerf3 has been a command-line tool. To use it on your phone, you’d either tether to a laptop, SSH into a Linux box, or — depending on the year — install a third-party shell on a jailbroken device. None of those are realistic for most people who actually want to test a Wi-Fi link from a phone.

The native iPerf3 Client & Server app on iOS, iPadOS, macOS, and Android removes that constraint. The same iperf3 wire protocol, GUI-driven, on the device that lives in your hand. This post walks through how to set it up, what each parameter actually does, and how to read a result on a mobile screen without the muscle memory of a terminal.

What you can do from a phone

The mobile app supports the same two roles as the command-line iperf3 binary:

• Client mode. The phone initiates a test against an iPerf3 server somewhere on the network. This is the most common use — phone in your hand, server on the wired side, measuring Wi-Fi throughput.
• Server mode. The phone is the iPerf3 server. Any other iperf3-speaking device (a Mac, a Linux box, another phone) can run a client against it. Useful when the phone’s incoming-traffic path is what you’re measuring, or when one phone tests another.

Both modes support TCP and UDP. Both run on the actual radio of the actual device — not through a bridge or proxy. That matters: a Wi-Fi test is only meaningful if it’s measuring the link the phone actually uses.

Quick setup: client mode against a Mac or Linux box

The fastest path to a first result:

1. On your wired computer, install the standard iperf3 binary if it isn’t already there:
   • macOS with Homebrew: brew install iperf3
   • Linux (Debian / Ubuntu): sudo apt install iperf3
   • Or run the iPerf3 Client & Server app on the Mac in Server mode for a GUI option.
2. Start the server: iperf3 -s (or tap Server mode in the app). Default port is 5201.
3. Find the computer’s LAN IP: ipconfig getifaddr en0 on macOS, ip addr on Linux. Looks like 192.168.1.42.
4. On the phone, open the iPerf3 app. Stay in Client mode. Enter the IP and port. Pick TCP. Tap Start.

A live speedometer ticks up to your real Wi-Fi throughput. After about ten seconds, the test ends and a result card appears.

Reading the result on a mobile screen

The result card after a test surfaces these numbers in order of usefulness:

• Average bandwidth in Mbps. The headline. This is the throughput the link delivered over the test duration.
• Maximum and minimum. The spread tells you how stable the link is. A 600 Mbps average with a 250–800 Mbps spread is much less reliable than a 600 Mbps average with 580–620 range.
• Latency / RTT. Round-trip time, in milliseconds. Low single digits on a wired LAN, 2–10 ms on a clean Wi-Fi.
• Retransmits (TCP). How many packets had to be resent. More than a handful on a 10-second test means link quality is degraded.
• Jitter and packet loss (UDP). Only shown for UDP tests. Jitter under 30 ms and loss under 1% are typical thresholds for real-time apps.

Tapping the result opens a detailed view with per-interval bandwidth graphs, TCP window size, MSS, PMTU, and the raw iperf3 output if you want to copy it into a ticket or paste into a chat.

Picking parameters: what actually matters

The app exposes the same knobs as the command-line tool. Most of them have defaults that are right 90% of the time. The two that genuinely matter for mobile testing:

• Protocol (TCP or UDP). TCP for throughput, UDP for stability. Use TCP first; switch to UDP only when diagnosing jitter or packet loss.
• Parallel streams (1–10). One TCP stream rarely saturates a modern Wi-Fi link. For Wi-Fi 6 or 6E, raise this to 4 or 8. For 2.4 GHz or older Wi-Fi 5, the default of 1 is usually fine.

Less commonly useful but available:

• Duration. Default 10 seconds for the standard test, 8 for a quick test, 15 for an extended test. Longer durations (60+ seconds) help if you suspect buffer bloat or thermal throttling.
• Direction. Download (server → client), Upload (client → server), or Bidirectional. Most “is my Wi-Fi slow?” questions are symmetric, but VPN tests often differ by direction.
• UDP bitrate. Only relevant in UDP mode — you specify the target sending rate, and the result tells you whether the link could carry it without drops.

Server mode on the phone

To make the phone itself the iPerf3 server:

1. In the app, switch to Server mode.
2. Confirm or change the listen port (default 5201).
3. Tap Start. The screen shows the device’s local IP and a “Listening” state.
4. From any other device, run an iperf3 client against <phone-ip>:5201. From another phone with the same app, point the client there. From a Mac terminal: iperf3 -c <phone-ip>.

The phone reports connected clients and the metrics from their sessions. When you’re done, tap Stop.

Why phone-as-server matters: it lets you test the incoming side of a phone’s network stack, which is the side that matters for receiving Plex streams, FaceTime calls, or large downloads. It also lets you test two phones against each other when no other device is available.

Phone-to-phone testing

For the two-phone scenario:

1. Phone A: Server mode. Note the IP.
2. Phone B: Client mode. Enter Phone A’s IP. Run the test.
3. (Optional) Swap roles to measure the reverse direction independently. Some Wi-Fi networks treat upstream and downstream asymmetrically.

This is the fastest way to test a Wi-Fi network with no other equipment — no NAS, no laptop, no router login. Useful when you’re at a customer site, in a hotel, or in any unfamiliar environment.

Apple Shortcuts and automation

On iOS, iPadOS, and macOS, the app exposes Apple Shortcut actions and a custom URL scheme:

• Run iPerf Test — start a test from a Shortcut with parameters (server, protocol, direction, duration).
• Get Last Result — pull the most recent result into a Shortcut.
• Test Server — check whether a configured server is reachable.
• List Servers — return saved servers for selection in a Shortcut chain.

The default duration for Shortcut-triggered tests is 5 seconds — chosen so a scheduled background test stays brief. Override it explicitly in the Shortcut if you want a longer run.

The URL scheme is iperf3cs://x-callback-url/run-test (and /get-last-result). On macOS, the Shortcuts Open URL action drives it; from Terminal, open "iperf3cs://x-callback-url/run-test?..." works the same way. This is how you wire iPerf3 into a CI pipeline, a HomeKit automation, or a calendar-driven nightly run.

Common iOS and Android caveats

• iOS background limits. Long-running tests need the app in the foreground. For multi-minute runs, disable auto-lock and plug the device in.
• iOS local-network permission. First-time use prompts for “Allow access to local network.” Without it, the app can’t reach LAN endpoints — both client and server modes need it.
• Cellular vs Wi-Fi. Tests run on whichever interface the OS selects by default. If both Wi-Fi and cellular are connected, iOS will usually prefer Wi-Fi for LAN destinations.
• Battery saver. Aggressive low-power mode can throttle CPU and reduce UDP throughput on older hardware. Compare client-reported vs server-reported bandwidth to spot CPU-bound bottlenecks.
• VPN profiles. If a system-wide VPN is active, the iperf3 traffic goes through the tunnel. To test the bare network, disconnect the VPN first.

When to use the phone app vs the CLI

The native app and the CLI binary are wire-compatible — both speak the same iperf3 protocol. Pick the one that matches the device you’re already on:

Scenario	Right tool
Testing Wi-Fi from a phone	Phone app
Walking a house room-by-room	Phone app
Running scheduled nightly tests on a server	CLI
Scripting tests from a Mac in CI	Mac app + Shortcuts, or CLI
Demoing a result to a non-technical person	Phone app
Capturing raw JSON for a Grafana dashboard	Either — both export the same fields

There’s no functional gap between the two for normal testing. The difference is ergonomics: which device is already in your hand, and whether you need a GUI to show a customer or a CLI to script.