Running an iPerf3 Server: Daemon Mode, Ports, and Logging

Every iPerf3 test needs a listening server, and how you run that server decides whether testing is a 10-second task or a small project. This article covers foreground and daemon modes, custom ports, logging, the one-client-at-a-time behavior that trips everyone up, and the firewall rules a test server needs - all demonstrated on a live lab server with real output. It is part of our complete iPerf guide.

Foreground Mode: The Quick Test

server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

The server binds TCP and UDP port 5201 on all addresses and prints each test's results to the terminal as it happens. This is fine for a one-off, but it dies with your SSH session. Two useful companions: -p to change the port and -1 (one-off mode) to exit automatically after a single test, which is handy in scripts.

Daemon Mode: The Persistent Server

server:~$ iperf3 -s -D --logfile /var/log/iperf3.log
server:~$ ss -ltn | grep 5201
LISTEN 0      4096               *:5201            *:*

The -D flag backgrounds the process; --logfile captures what would have gone to the terminal (without it, a daemonized server's output simply vanishes). The log shows the server-side view of every test, which is often the half of the story people forget to look at:

server:~$ tail /var/log/iperf3.log
[  6]   7.00-8.00   sec  1.12 MBytes  9.44 Mbits/sec
[  6]   8.00-9.00   sec  1.12 MBytes  9.43 Mbits/sec
[  6]   9.00-10.00  sec  1.12 MBytes  9.45 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  6]   0.00-10.53  sec  11.9 MBytes  9.46 Mbits/sec                  receiver

One Test at a Time (and the Busy Error)

An iPerf3 server process runs exactly one test at a time. Here is what a second client sees while a test is in progress - captured from a real client hitting our lab server mid-test:

j@llmbits:~$ iperf3 -c 10.0.20.10
iperf3: error - the server is busy running a test. try again later

This is by design (iPerf2 behaves differently; see iPerf2 vs iPerf3). The standard workaround is one server process per port:

server:~$ iperf3 -s -D --logfile /var/log/iperf3-5201.log
server:~$ iperf3 -s -p 5202 -D --logfile /var/log/iperf3-5202.log
server:~$ ss -ltn | grep 520
LISTEN 0      4096               *:5201            *:*
LISTEN 0      4096               *:5202            *:*

Clients pick their lane with the same flag: iperf3 -c 10.0.20.10 -p 5202. Two processes, two simultaneous tests, no waiting. Teams that share a test box often run four or five daemons on consecutive ports.

Running iPerf3 as a systemd Service

For a permanent test server, let systemd own the process so it survives reboots:

# /etc/systemd/system/iperf3.service
[Unit]
Description=iperf3 server
After=network-online.target

[Service]
ExecStart=/usr/bin/iperf3 -s --logfile /var/log/iperf3.log
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now iperf3

Note there is no -D here: systemd wants the process in the foreground so it can supervise it.

Firewall Rules and Network Access

iPerf3 uses a single port (default 5201) for both the TCP control connection and the test traffic, TCP or UDP. Open both protocols on whatever port you chose:

# Linux (firewalld)
sudo firewall-cmd --add-port=5201/tcp --add-port=5201/udp --permanent
sudo firewall-cmd --reload

# Linux (ufw)
sudo ufw allow 5201

If the path crosses a Cisco device with an ACL, permit the same port pair. A client that hangs at "Connecting to host..." then times out usually means the control connection (TCP 5201) is blocked; a UDP test that starts but reports 100% loss usually means TCP got through and UDP did not - an asymmetric ACL is the first thing to check.

Useful Server-Side Flags

Reading the Server Side During Tests

The server's report is not a mirror of the client's. On a TCP test, the client prints sender-side detail (Retr and Cwnd columns), while the server log records the receiver's view - what actually arrived, interval by interval. When a client-side summary looks odd (say, the sender claims 34 Mbit/sec but the transfer felt slower), the server log settles it. On UDP tests the asymmetry is even more valuable: jitter and loss are computed at the server, so the authoritative numbers live in the server output and are echoed back to the client at test end. If you daemonize with --logfile, you get a permanent, timestamped record of every test anyone has run against that box - which quietly becomes your best throughput history when a "was it always this slow?" question shows up months later (baseline discipline, same as we recommend in troubleshooting slow throughput).

A Word on Exposure

An iPerf3 server is a machine that will saturate a link on request - do not leave one listening on an internet-facing interface. Anyone who finds it can burn your bandwidth all day, and historical CVEs have targeted the server side. Keep test servers on management networks, bind them to internal addresses with -B, firewall the port to known sources, and prefer -1 one-shot servers where practical. Public iperf servers exist for WAN sanity checks, but treat results through the internet as indicative, not diagnostic.

Key Takeaways

Use plain iperf3 -s for quick checks, -D --logfile for persistent daemons, and systemd for anything permanent. One process serves one test at a time, so multiple ports are the answer to the busy error. Open your chosen port for both TCP and UDP, bind deliberately on multihomed hosts, and never expose a test server to the open internet. With the server side squared away, the client-side techniques are covered across the rest of the iPerf complete guide, starting with how to use iPerf3.