How to Test Your LAN Speed (Not the Internet): The Right Way

You bought a 2.5 GbE switch. You upgraded the NAS to NVMe. You ran new Cat6a cable through the wall. Then you opened Speedtest, hit Go, and got 940 Mbps. Same as before. What just happened?

Nothing. Speedtest is the wrong tool for this job. It measures your internet connection: the path from your device to a server somewhere on the public internet. It cannot see the link between your laptop and your NAS, because that traffic never leaves the LAN. If you want to know whether your local network is actually delivering the speed it should, you need a LAN speed test, not an internet speed test. The right tool is iPerf3.

This post walks through running an iPerf3 LAN test in about five minutes, with no command line, on whatever devices you already have.

What “LAN speed” actually means

Your LAN (local area network) is everything between the devices in your home or office: ethernet switches, Wi-Fi access points, the LAN side of the router, and the cables between them. Your WAN is everything beyond that: the modem, the ISP, the public internet.

Speedtest tools measure the slowest hop end to end, from your device to a remote server. They cannot isolate the LAN. iPerf3 measures the throughput between two endpoints you control, on a network segment you choose. If both endpoints are on your LAN, the result is your LAN speed. The internet is not involved.

What you need

iPerf3 works in a client/server pair. One device runs as the server, the other connects as the client, and you read the throughput off the client’s screen. You need two devices that can both run iPerf3:

• One acts as the server.
• One acts as the client.
• Both must be reachable from each other on the LAN (same subnet, no firewall blocking port 5201).

That’s it. You don’t need a dedicated benchmarking server, a Linux box, or any kind of subscription. Two devices, both running the same iperf3 protocol, talking to each other.

Picking your two endpoints

Three common pairings:

1. Phone ↔ Mac/PC. The most common. Phone runs the iPerf3 client (where you’re standing), Mac or PC on Ethernet runs the server. Tests your Wi-Fi link end to end.
2. Phone ↔ phone. Two phones, one as server, one as client. Tests pure Wi-Fi-to-Wi-Fi performance without any wired hop.
3. Phone ↔ NAS or router. If your NAS, router, or homelab box runs iperf3, point the phone at it. Tests the exact link you care about: the one between your device and your storage.

For the rest of this guide I’ll assume the most common case: a phone as the client and a Mac on Ethernet as the server. The same steps apply to any pairing.

Step 1: Start the server

On the Mac (or any device that’s going to play the server role):

1. Open iPerf3 Client & Server.
2. Switch to Server mode.
3. Note the port. The default is 5201. Leave it unless you have a reason to change.
4. Tap Start. The app shows “Listening on 5201” or equivalent.
5. Note the device’s local IP. On macOS: System Settings → Network → click the active connection → Details. Looks like 192.168.1.42 or 10.0.0.10, not 127.x.x.x and not the public IP.

The server now waits for a client to connect. It will stay idle until you start a test from the other device.

Step 2: Connect the client

On the phone (or whichever device is the client):

1. Open iPerf3 Client & Server.
2. Make sure Client mode is selected.
3. Enter the server’s IP: the 192.168.1.42 you noted earlier.
4. Confirm port 5201.
5. Pick TCP for raw throughput.
6. Tap Start.

The test runs for the default duration (usually 10 seconds), shows a live speedometer of bandwidth, then prints a final number. That number is your LAN throughput between this phone and that Mac.

Step 3: Read the result

The result has three useful parts:

• Average Mbps or Gbps: the headline number. This is your effective throughput.
• Peak/min: how stable the link is. Big spread = interference or congestion.
• Retransmits: how many TCP packets had to be resent. Higher = degraded link.

For Wi-Fi tests, also note where you’re standing. The same iPhone may show 600 Mbps near the AP and 90 Mbps in the basement. That delta is your Wi-Fi coverage map, one data point at a time.

Typical numbers: what’s normal?

Link	Expected throughput
Gigabit Ethernet (1000Base-T)	920 to 960 Mbps
2.5 GbE	2.3 to 2.4 Gbps
10 GbE	9.0 to 9.4 Gbps
Wi-Fi 5 (802.11ac), close range	400 to 700 Mbps
Wi-Fi 5, one wall away	150 to 350 Mbps
Wi-Fi 6 (802.11ax), close range	700 Mbps to 1.5 Gbps
Wi-Fi 6, one wall away	300 to 700 Mbps
Wi-Fi 6E (6 GHz band), close range	1 to 2 Gbps
Mobile hotspot tethering	30 to 150 Mbps

These are realistic real-world numbers, not marketing spec. If you see less, the bottleneck is somewhere in the link: phone radio, AP, switch, cable, or the device on the other end.

Step 4: Pin down the bottleneck

If the number is lower than you expected, isolate variables one at a time:

1. Move closer to the AP. If the number jumps, your bottleneck is Wi-Fi range.
2. Run a second client on the same Wi-Fi. If both show similar low numbers, the AP or backhaul is the cap, not this device.
3. Repeat the test with the phone on Ethernet (USB-C adapter for iPad / iPhone 15+). If Ethernet gives full-speed but Wi-Fi doesn’t, the radio link is the bottleneck.
4. Swap server roles: make the phone the server, Mac the client. Results should be symmetric. If they aren’t, one device’s networking stack is the limit.
5. Try parallel streams: set 4 or 8 parallel TCP streams in the app’s test settings. Single-stream TCP often doesn’t saturate modern Wi-Fi; multi-stream usually does.

By the third or fourth iteration, you’ll have a concrete answer to “where is the speed disappearing?” instead of guessing.

When you want UDP instead of TCP

TCP is right for “how much bandwidth?” UDP is right for “how stable is the link?” That means jitter, packet loss, and bufferbloat. Use UDP mode when:

• You’re diagnosing choppy Zoom or Teams calls.
• You’re testing gaming latency on Wi-Fi.
• You want to confirm that a buffering issue is the network, not the app.

The app switches between TCP and UDP with one toggle. UDP results show jitter in milliseconds and packet loss as a percentage. Those are what you’d report to a network engineer or vendor, not bandwidth alone.

Why a native app

iPerf3 on the command line works fine if you live in a terminal: iperf3 -c 192.168.1.42 -p 5201. Most people don’t. A native iPerf3 app on iOS, iPadOS, macOS, and Android lets you:

• Run the test from the device that’s actually in your hand.
• Save sessions and compare them over time (e.g. “before mesh upgrade” vs “after”).
• Walk through the house collecting data points without a laptop.
• Export results as CSV or JSON if you need them in a spreadsheet or report.

The wire protocol is identical to the standard iperf3 binary, so results are directly comparable to anything else in the ecosystem: homelab dashboards, Grafana panels, network engineer reports.

Bottom line

The next time you upgrade a router, swap an AP, or add a mesh node, don’t rerun Speedtest and shrug. Run iPerf3 against a known-good device on your LAN, before and after. You’ll see the actual delta from the change, separated cleanly from whatever your ISP happens to be doing today.

That’s the difference between “I think it’s faster?” and “my Wi-Fi link is now 1.3 Gbps where it was 700 Mbps.” One of those is data. The other is hope.