# XIU2/CloudflareSpeedTest: picking the fastest Cloudflare IP from the command line

> The tool scans Cloudflare's published IP ranges, measures TCP or HTTP latency, then downloads through the lowest-latency candidates and writes a sorted result.csv. It is built for people who route traffic to Cloudflare and are unhappy with the IP the resolver hands them.

**XIU2/CloudflareSpeedTest** — 🌩「自选优选 IP」测试 Cloudflare CDN 延迟和速度，获取最快 IP ！当然也支持其他 CDN / 多个解析 IP 的网站 ~

- Repository: https://github.com/XIU2/CloudflareSpeedTest
- Stars: 29,204 · Forks: 5,475
- Language: Go
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/xiu2-cloudflarespeedtest

## Why a Cloudflare IP list is not the same as a good Cloudflare IP

Cloudflare publishes its IP ranges, and every visitor to a site behind the CDN gets assigned one of those addresses by DNS. The README's premise is blunt: the addresses handed to visitors in mainland China are often poor, with high latency, packet loss and low throughput. Knowing the full range does not help, because the range is enormous and the useful subset changes over time and by network.

So the project does not try to be clever about routing. It brute-forces the question: measure a lot of candidate addresses, keep the ones that answer quickly, then measure how fast data actually moves through them. The output is a short ranked list, and the ranking is the product. That framing matters, because it tells you who the tool is for. It is for someone who can act on the result, meaning someone who sets a fixed edge IP in a client, a proxy config or a hosts entry. If nothing downstream consumes the IP, the CSV is trivia.

The README also states the tool works against other CDNs and any site that resolves to multiple IPs, with the caveat that you have to supply your own download test URL. That is a genuine widening of scope, not a marketing line, and it is the part most people miss on first read.

## The five stages between launch and result.csv

The README spells out the default pipeline in five steps. First, latency testing over the candidate addresses, using TCPing by default; HTTPing is available but requires an explicit flag. Second, sorting by latency from low to high, with filtering applied at this point. Third, download testing, starting from the lowest-latency address and stopping once the default target of 10 measurements is reached. Fourth, sorting by speed from high to low. Fifth, output, which the flags control.

Two details in that sequence are worth pausing on. The first is that addresses with different packet loss rates are sorted into separate groups, so a low-latency address with loss can end up below a higher-latency address without it. That is a deliberate ordering choice, and it means the top row is not simply the lowest ping. The second is that the download stage is capped by default at 10 addresses, which is what keeps a run bounded. The latency stage touches far more addresses than the download stage ever will.

The code is a single Go module, github.com/XIU2/CloudflareSpeedTest, targeting Go 1.18, with a small dependency set: ewma for moving averages, pb/v3 for the progress bar, and fatih/color for terminal output. The repository layout is flat, with main.go at the root and ip.txt and ipv6.txt holding the candidate ranges. There is no server component and no daemon. Each run is a standalone process that reads its inputs and exits.

## Installing on Windows, Linux and macOS

The primary distribution path is a prebuilt binary from the releases page. On Windows the README's quick start is to download the release archive, extract it, and double-click cfst.exe, then wait for the test to finish. There is also a scoop route through the dorado bucket, shown below exactly as the README gives it.

```bash
scoop bucket add dorado https://github.com/chawyehsu/dorado
scoop install dorado/cloudflare-speedtest
```

On Linux and macOS the README walks through downloading the latest tarball, extracting, marking it executable and running it. The commands below are the ones the README lists, with the version-specific download left to the releases page.

```bash
mkdir cfst
cd cfst
wget -N https://github.com/XIU2/CloudflareSpeedTest/releases/latest/download/cfst_linux_amd64.tar.gz
tar -zxf cfst_linux_amd64.tar.gz
chmod +x cfst
./cfst
```

The README notes that the latest/download URL always points at the newest release, and that a specific version can be pinned by editing the filename, for example cfst_linux_amd64.tar.gz under a v2.3.4 tag path. It also lists several mirror prefixes for readers downloading from mainland China, including wget.la and ghfast.top, and suggests dropping the -N flag if the download fails.

A first run with no arguments uses defaults. To change the shape of the run, the README's own example passes two flags:

```bash
./cfst -tl 200 -dn 20
```

After the progress bar completes, the terminal shows the fastest 10 addresses by default, with columns for IP address, sent, received, packet loss, average latency, download speed in MB/s and a region code. The same data lands in result.csv in the working directory, with a header row and one line per address. The README warns that opening that file in Microsoft Excel shows garbled Chinese characters, and that other spreadsheet software and plain text editors display it correctly.

## The proxy trap and the 0.00 download column

The most common way to get a useless result is to leave a proxy running. The README states this plainly: if average latency comes out very low, in the 0.xx range, the test went through a proxy, and the proxy should be closed before measuring. The same warning applies to running on a router, where an internal proxy should be disabled or excluded or the results may be inaccurate or unusable. This is not a subtle failure mode. It produces numbers that look excellent and mean nothing, because you measured the path to your proxy rather than the path to Cloudflare.

The second documented failure is a download speed column of 0.00 across the board. The README points to a debug mode, invoked with the -debug flag, for diagnosing it, and links a dedicated section of the document. It does not promise a single cause.

There is also a warning about the first run after boot: the README states that latency is noticeably higher on the first test after the machine starts, and that manual TCPing shows the same behaviour. The suggested workaround is to run a throwaway pass first, killing it as soon as the progress bar moves, before the real measurement. That is an odd thing to have to document, but it is honest, and it tells you the tool inherits the host's network stack warm-up rather than controlling for it.

Finally, the README carries an explicit notice that Cloudflare has prohibited proxy use of the CDN in its terms, that anyone layering a proxy over the CDN does so at their own risk, and that the project should not be relied on too heavily for that purpose. It links two discussions on the topic. Whatever the tool measures, that constraint sits outside it.

## Where it stops: UDP, WARP and general speed testing

The README is direct that the software is for websites only and does not support picking IPs for Cloudflare WARP, which uses UDP. Anyone arriving from a WARP context and expecting the same workflow will find the tool measuring the wrong thing entirely, since its latency and download stages are built around TCP and HTTP.

The second boundary is conceptual. This is not a speed test in the Ookla sense of reporting your line rate. It does not tell you what your connection is capable of in the abstract; it tells you which of a set of candidate addresses responded best from this machine, on this network, at this moment. The README notes that because each run samples random addresses within each range, no two runs produce identical results, and that this is expected. Anyone treating a single CSV as a permanent configuration is misreading the output. It is a snapshot with a short shelf life.

The third boundary is the download target. Against Cloudflare the tool has a download test endpoint to work with. Against another CDN or a multi-IP website, the README says you must find your own download test address. Without one, you are limited to the latency stage, and the speed ranking that makes the top row meaningful disappears.

## How it differs from a browser speed test

A browser-based speed test measures one path, chosen by whatever DNS returned, and reports throughput, latency, jitter and sometimes packet loss. It answers the question how good is my connection right now. CloudflareSpeedTest answers a different question: among many candidate addresses for the same service, which ones are fastest from here. The two are not substitutes, and the search interest around Cloudflare speed tests tends to blur them.

The practical difference is what you do with the result. A browser test ends with a number you can compare against your plan. This tool ends with a list of IP addresses you can paste into a configuration. It also produces per-address packet loss and a region code, which a single-path browser test cannot, because it only ever sees one address. The cost is scope: no jitter metric, no upload measurement, no notion of your line's ceiling.

If your actual need is to know whether your ISP is delivering what you pay for, this is the wrong tool and a browser test is the right one. If your need is to stop a specific service from routing you through a bad edge, the browser test cannot help you at all.

## Licence, maintenance and what an upgrade costs

The project is GPL-3.0. For the common case, running the prebuilt binary to produce a CSV, the licence imposes nothing on your own code, because you are not distributing a derivative work. The obligation attaches if you redistribute the software or ship a modified version, at which point the copyleft terms apply to that distribution. That is a general description of how GPL-3.0 works, not legal advice, and anyone embedding the code in a product should read the licence text in the repository.

The last push to the repository was on 2026-09-15, and the repository is not archived. The most recent release listed is v2.3.5 on 2026-04-29, described as making connection release faster after each HTTPing or download test completes. Before that, v2.3.4 on 2025-07-22 updated dependency versions and fixed an issue with coloured text, and v2.3.3 on 2025-07-21 fixed the number of results output when no download speed floor was set. The cadence is irregular: a burst of fixes in July 2025, a gap, then a release in April 2026. Nothing about that pattern suggests the project is abandoned, and nothing suggests a predictable schedule either.

Upgrade cost is low by design. There is no installer, no service and no state beyond the binary, the ip.txt and ipv6.txt range files, and the result.csv it writes. The README's Linux instructions note that extracting over an existing directory overwrites in place, so updating means downloading the new tarball and extracting again. The one thing to re-check after an upgrade is whether your flags still behave the same way, since v2.3.3 was itself a fix to output counts under particular conditions.

## Conclusion

Adopt it if you already control which Cloudflare edge IP your client or proxy connects to and you want a measured, repeatable shortlist instead of guessing. Skip it if you need a general internet speed test, if you are testing Cloudflare WARP (the README states UDP is not supported), or if you cannot accept the proxy risk the project itself flags. Before trusting any run, verify three things: that no proxy is active on the machine or router, that the average latency column is not suspiciously close to zero, and that the download speed column is not 0.00 for every row. The project's own advice is to run one throwaway pass after boot, because the first measurement on a freshly started machine reads high.

## FAQ

### Is XIU2/CloudflareSpeedTest reliable?

It measures what it measures: latency and download speed from your machine to sampled Cloudflare addresses at that moment. The README states that each run samples random IPs within each range, so results differ every time, and that a proxy running during the test produces meaningless low latency figures.

### What is XIU2/CloudflareSpeedTest?

It is a Go command line tool that tests latency and download speed across Cloudflare CDN IP ranges and outputs the fastest addresses, IPv4 and IPv6, to the terminal and to result.csv. The README also states it can test other CDNs or multi-IP websites if you supply a download test address.

### How is XIU2/CloudflareSpeedTest different from a browser speed test?

A browser test measures one path and reports your connection's throughput. This tool tests many candidate addresses and ranks them, producing a per-address list with packet loss, average latency and a region code that you can act on in a client or proxy configuration.

### What alternatives exist to XIU2/CloudflareSpeedTest?

For measuring your own connection, a browser-based speed test covers throughput, latency and jitter but only over the single address DNS returns. The README notes this project also works against other CDNs and multi-IP sites, provided you find a download test URL yourself.

## Sources

- [Issues](https://github.com/XIU2/CloudflareSpeedTest/issues)
- [License: GPL-3.0](https://github.com/XIU2/CloudflareSpeedTest/blob/master/LICENSE)
- [README](https://github.com/XIU2/CloudflareSpeedTest/blob/master/README.md)
- [Releases](https://github.com/XIU2/CloudflareSpeedTest/releases)
- [XIU2/CloudflareSpeedTest on GitHub](https://github.com/XIU2/CloudflareSpeedTest)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xiu2-cloudflarespeedtest