How to Test Local LAN & WiFi Speed with iperf3
Test your true local LAN and WiFi throughput independent of ISP bottlenecks by running iperf3 -s on a wired PC or NAS and executing iperf3 -c
- Start the Server: Run
iperf3 -son a wired machine connected via 1GbE, 2.5GbE, or 10GbE Ethernet and open TCP/UDP port5201in your host firewall. - Forward (Upload) Test: Run
iperf3 -c 192.168.1.50 -P 4 -t 15from your laptop or phone to measure client-to-server throughput across 4 parallel TCP streams. - Reverse (Download) Test: Add the
-Rflag (iperf3 -c 192.168.1.50 -P 4 -t 15 -R) so the wired server sends data to your wireless device. - Spot Bad Cables Instantly: Watch the
Retr(TCP Retransmissions) column—a healthy wired Cat6/Cat6a link should show0retransmissions and941 Mbps(1GbE) or2.35 Gbps(2.5GbE).
Why Speedtest.net Cannot Diagnose Internal LAN or Wi-Fi Bottlenecks
When you run a browser test on Speedtest.net or Fast.com, you are testing the slowest link in a chain spanning your client device, Wi-Fi access point, Ethernet wall jack, network switch, router NAT engine, cable/fiber modem, and your ISP's peering link. If you pay for a 300 Mbps internet plan and get 300 Mbps on Speedtest, you have zero visibility into whether your new Wi-Fi 7 access point is actually delivering 2.1 Gbps locally or whether your in-wall Cat6 cable is silently degrading to 100 Mbps Fast Ethernet.
iperf3 is the industry-standard open-source network throughput benchmarking tool developed by ESnet and Lawrence Berkeley National Laboratory. It generates synthetic TCP or UDP payloads entirely in system RAM (removing SSD or hard drive read/write bottlenecks) between two endpoints on your local subnet. By wiring an iperf3 server directly into your core switch and walking through your home or office with a client laptop or smartphone, you can measure exact physical throughput in every room.
Step 1: Set Up an iperf3 Server on Windows, macOS, Linux, or NAS
For accurate wireless or switch testing, your iperf3 Server must be connected via wired Ethernet (ideally 2.5GbE or 10GbE when testing Wi-Fi 6E/7) so the server's own network link never becomes the bottleneck:
- Linux (Ubuntu/Debian) / Raspberry Pi: Run
sudo apt update && sudo apt install iperf3 -y, then start the listener withiperf3 -s. - macOS (via Homebrew): Run
brew install iperf3, then executeiperf3 -s. - Windows 11: Install via Winget (
winget install Artois.iPerf3or download the official binary), open PowerShell in that folder, and run.\iperf3.exe -s. When Windows Defender Firewall prompts you, check both Private and Public networks (or allow inbound TCP/UDP port5201). - Synology NAS / TrueNAS / Unraid (Docker): Run a persistent container so a test server is always ready on your LAN:
docker run -d --name=iperf3-server -p 5201:5201/tcp -p 5201:5201/udp --restart unless-stopped networkstatic/iperf3 -s.
Step 2: Essential iperf3 Client Commands (-P 4, -R, -u, --bidir)
Assume your wired iperf3 server has the IP address 192.168.1.50. On your client laptop, desktop, or mobile app (such as iPerf3 WiFi Speed Test on iOS or Magic iPerf / Termux on Android), run these four diagnostic tests:
- 1. Multi-Stream Upload Test (Client to Server):
iperf3 -c 192.168.1.50 -P 4 -t 15. Using-P 4(4 parallel TCP streams) is critical on Wi-Fi 6/7 and 2.5GbE/10GbE links because a single TCP window often cannot saturate high-bandwidth-delay pipes. - 2. Multi-Stream Download Test (Server to Client):
iperf3 -c 192.168.1.50 -P 4 -t 15 -R. The-R(Reverse) flag instructs the server to transmit data to your client, measuring your true Wi-Fi download speed. - 3. Full-Duplex Bidirectional Test:
iperf3 -c 192.168.1.50 --bidir -t 15. Transmits and receives simultaneously to verify a wired switch link is operating at true full-duplex (e.g., 940 Mbps TX + 940 Mbps RX concurrently) and to test Wi-Fi 7 MLO STR links. - 4. UDP Jitter & Packet Loss Test (VoIP/Gaming Simulation):
iperf3 -c 192.168.1.50 -u -b 100M -t 15. Sends a constant 100 Mbps UDP stream and outputs exact Jitter (ms) and Lost/Total Datagrams (%).
How to Interpret iperf3 Output: Goodput Overhead vs TCP Retransmissions
New users are often surprised when a healthy 1,000 Mbps Gigabit Ethernet port reports 941 Mbits/sec in iperf3 instead of 1,000 Mbits/sec. This is completely normal: TCP/IP headers (20 bytes IPv4 + 20 bytes TCP + 12 bytes TCP timestamps) and Ethernet framing (38 bytes including preamble and inter-packet gap) consume roughly 5.86% overhead on standard 1,500-byte MTU frames. A 1GbE link maxes out at 941 Mbps, a 2.5GbE link maxes out at 2.35 Gbps, and a 10GbE link maxes out at 9.41 Gbps (or 9.90 Gbps with 9,000-byte Jumbo Frames).
Instead of chasing that 5.8% protocol overhead, inspect these three red flags in your output:
- Exactly 94.1 Mbps on a Wired Port: Your Ethernet cable has a broken pin on pair 3 or 4 (pins 4, 5, 7, or 8), forcing the NIC to downshift from 1000BASE-T to 100BASE-TX Fast Ethernet.
- High
Retr(Retransmissions) on Wired LAN: On Linux/macOS sender output, theRetrcolumn should be0(or single digits over 15 seconds) on wired Ethernet. Hundreds of retransmissions indicate a bad keystone punchdown, EMI interference, a failing SFP+ transceiver, or flow-control mismatches when stepping down from a 2.5GbE server to a 1GbE client.
Expected Real-World iperf3 TCP Throughput Benchmarks (1500 MTU)
| Network Link Type | Physical Link / PHY Rate | Expected iperf3 Goodput | Healthy TCP Retr / Jitter |
|---|---|---|---|
| Fast Ethernet (Bad Pin / Old Switch) | 100 Mbps Full-Duplex | 94.1 Mbps | 0 Retr / <0.2 ms jitter |
| Gigabit Ethernet (1000BASE-T Cat5e/6) | 1,000 Mbps Full-Duplex | 940–942 Mbps | 0 Retr / <0.1 ms jitter |
| 2.5GBASE-T Multi-Gig Ethernet (Cat6) | 2,500 Mbps Full-Duplex | 2.35–2.37 Gbps | 0–5 Retr / <0.1 ms jitter |
| 10GBASE-T / SFP+ (Cat6a / DAC) | 10,000 Mbps Full-Duplex | 9.41 Gbps (9.90 Gbps w/ MTU 9000) | 0–15 Retr / <0.05 ms jitter |
| Wi-Fi 6 (5 GHz, 80 MHz, 2x2 Client) | 1,201 Mbps PHY (Half-Duplex) | 650–850 Mbps (Same Room) | <50 Retr / 1–3 ms jitter |
| Wi-Fi 6E / 7 (6 GHz, 160/320 MHz, 2x2) | 2,402–5,764 Mbps PHY | 1.40–3.80 Gbps (Requires 2.5G/10G AP) | <80 Retr / 0.5–2 ms jitter |
iperf3 LAN & Wi-Fi Diagnostic Troubleshooting Checklist
- Connect your iperf3 server computer or NAS via wired Ethernet (at least as fast as the link you are testing) and verify its NIC speed is 1000/2500/10000 Mbps.
- Allow inbound TCP and UDP port 5201 on the server's operating system firewall before starting iperf3 -s.
- Run a wired-to-wired baseline test first (expecting 941 Mbps on 1GbE or 2.35 Gbps on 2.5GbE) to verify your switch and server are healthy.
- Use -P 4 (4 parallel streams) for all Wi-Fi and multi-gigabit tests, and run both normal (upload) and -R (download) directions.
- Check the Retr column on Linux/macOS/Android—if wired retransmissions exceed 10 per minute, replace the patch cable or re-terminate the wall keystone.
- Remember not to run iperf3 directly ON a consumer router's weak ARM CPU (which caps out at 300–500 Mbps generating traffic); always run iperf3 between two endpoints THROUGH the router or switch.
Frequently Asked Questions
Why do I only get 400 Mbps when running iperf3 directly on my router via SSH?
Generating and encrypting/checksumming synthetic TCP packets in user space is CPU-intensive. Consumer router ARM processors are built to forward packets in hardware ASICs, not generate them locally; always run iperf3 between two separate computers or a NAS and a client device.
Why does Windows iperf3 show slower single-stream speeds than Linux or macOS?
The official Cygwin-based Windows port of iperf3 has suboptimal socket buffer scaling on single TCP streams. Either pass -P 4 -w 2M to use 4 parallel streams with a 2 MB TCP window size, or run iperf3 inside WSL2 (Windows Subsystem for Linux) for native Linux kernel socket performance.
What does 'iperf3: error - unable to connect to server: Connection timed out' mean?
Either iperf3 -s is not actively running on the target IP address, the server's local firewall (such as Windows Defender Firewall or Linux ufw) is blocking TCP port 5201, or Wi-Fi Client Isolation / Guest VLAN rules are blocking LAN-to-LAN communication.
Can I test two Wi-Fi devices at the same time with one iperf3 server?
A single iperf3 -s instance only handles one active test at a time on port 5201. To test two clients simultaneously, start a second server process on a different port (e.g., iperf3 -s -p 5202) and connect the second client using iperf3 -c 192.168.1.50 -p 5202.