public-iperf3-servers: a maintained list of public iperf3 endpoints

The table is the product, and every row is a runnable command

This repository is a data set with a small amount of tooling around it, and the central artefact is a set of tables organised by continent. Each row carries the exact command you would type, the options that server supports, the port range, the country and the city. The Africa section alone shows servers in Luanda, Algiers, Cairo, Accra, Banjul, Bata, Nairobi, Floreal, Cape Town, Kampala and Johannesburg, and the columns record whether a server handles reverse mode, UDP, or IPv6, along with a port range such as 9210-9240 or 5201-5209. A typical entry looks like this:

iperf3 -c 102.130.68.171 -p 9210-9240

The value of that format is that it removes the guesswork. A generic list of servers would give you addresses and leave you to work out the port ranges and whether a given endpoint will accept UDP. Here the options column also tells you which measurements are even possible against a given host, and a server listed with the UDP option is one where a latency test over UDP is meaningful. The continent grouping is a differentiator from a flat list, because the point of a public server list is usually comparative: you want a baseline in Europe, one in North America and one in Asia or Oceania to see how your link behaves across distances, and the Asia section covers Dubai, several Chinese cities, Hong Kong, Jerusalem, Tel Aviv, Bengaluru, Pune, Tokyo and more.

Uptime below 90 percent gets a server removed

The list has a published quality policy, and that is what separates it from a directory of servers that nobody curates. The README states that servers with an uptime of 90 percent or less in 30 days will be removed, and it links to a dedicated 30 day uptime site for the list, and the header carries a badge showing the current uptime for the listed group over 30 days. The reasoning behind the threshold is not spelled out, but the effect is clear enough: a server that is down half the time is worse than no server, because a failed measurement and a slow measurement are hard to tell apart. The policy also implies a maintenance loop that has to be running, and the repository contains a testing_process.md document that describes the testing and monitoring side of things, plus a findtest.sh script at the root. A related operational detail worth knowing is that a server running in the list needs a range of ports open rather than a single one, which is visible in the port columns, and that is what the container image in the repository exposes.

The Dockerfile is a complete recipe for running your own server

The repository ships a container image definition that is short enough to read in one screen, and it tells you most of what you need to know to run an iperf3 server yourself. The file starts with a comment giving the pull command for the published image, then builds from alpine, adds iperf3 through the Alpine package manager, exposes the default server port for both TCP and UDP, and sets the entrypoint to the iperf3 binary with a server flag as the default command. The full set of lines is short:

FROM alpine
RUN apk add --update --no-cache iperf3
EXPOSE 5201/tcp 5201/udp
ENTRYPOINT ["/usr/bin/iperf3"]
CMD ["-s"]

Two things stand out. First, the image is Alpine based, so the whole thing is small, and iperf3 comes from the distribution repository rather than being compiled, which means the image tracks whatever the Alpine package version is rather than a pinned version of the tool. Second, the exposed port is the default iperf3 port on 5201 for both TCP and UDP, and the container exposes only that single port, while many of the servers in the list run on wide ranges such as 9202-9240 or 30001-30009, because a single port serialises measurements and a range lets several clients run at once. If you want to add your own server to the list, the process is stated in the README: you create a new issue on the repository with the address you want added or removed.

Where the measurement guidance lives, and what it cannot tell you

The README is mostly a table, so the substance about how to use it sits in a separate document called docs.md, and its section headings tell you what it covers. There is an installation section, a basic usage section, a section on test scenarios and protocol differences, and a section on advanced usage and tips. The protocol differences heading is the one to look at first if you are comparing numbers, because iperf3 can run several distinct tests, TCP and UDP, in reverse and forward direction, and with parallel streams, and the results are not comparable across those. The options column in the tables exists precisely so you can see which of those a given server supports, and the fact that reverse mode is marked on almost every row tells you the list favours the configuration that measures the server to client rather than the client to server, which is the useful direction when the server is not yours. The advanced section is where the tips live, and the guidance in the earlier sections is what stops a comparison from being meaningless. What none of this can do is control the server side. A public server sits behind an uplink you know nothing about, on hardware you did not choose, so the number it reports is a property of that path, not of your own link.

Exports, an uptime API and the surrounding service

The list is not only a markdown table. The table of contents points to an export section covering JSON, CSV and XLSX, which means the same data can be pulled into a script or a spreadsheet, and the uptime badge in the header points at an API endpoint under a v1 path for endpoints and uptimes, so the health of the list is queryable rather than only viewable. There is also a section for apps and a section for links, which suggests companion clients exist for consuming the list, and the site itself is served at iperf3serverlist.net with a separate site for the 30 day uptime data. The project states that it is sponsored and supported by HostHatch and by Censys, which is worth noting for two reasons. The first is that a list like this needs measurement infrastructure, and running probes against servers in six continents is not free. The second is that sponsorship is relevant to how much you should trust the uptime data, since the sponsor has a commercial interest in the list being useful and the removal policy is what keeps it honest. The main branch is where the list lives, the last push was on 2026-10-17, and there are no GitHub releases, so the repository is the artefact and there is nothing to install.

Editorial conclusion

public-iperf3-servers is a good fit for a network engineer who wants a quick comparison of throughput to several regions without provisioning servers, and for a reader who wants to see how a public measurement service is run and policed, since the testing process and the uptime removal rule are both documented. It is the wrong tool for a benchmark you intend to publish, because the endpoints are third party machines on unknown uplinks and the numbers say more about the server than about your connection, and it is the wrong tool if you need a controlled baseline, which means running your own iperf3 server, and the Dockerfile in the repository shows how little that takes. Before relying on any entry, check its current uptime badge rather than the table, since servers are removed when they fall below 90 percent over 30 days. The project is MIT licensed, the last push was on 2026-10-17, and it publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. R0GGER/public-iperf3-servers on GitHub
5. README