better-cloudflare-ip: A Go Tool for Finding Cloudflare Anycast IPs That Fit Your Network

What better-cloudflare-ip actually measures

Cloudflare announces the same IP ranges from many edge locations, so the address that performs best for one user can be mediocre for another. The project exists to answer a narrow question: given the IP ranges Cloudflare publishes, which single address in those ranges gives the best round-trip time and download speed right now, over this specific connection? The README frames the work as research into how packet loss and throughput relate inside anycast, and states the project is for study use. That framing matters. This is not a proxy, not a DNS resolver, and not a configuration manager. It produces a result, and the user decides what to do with it. The audience is therefore people who already know why they want a specific Cloudflare edge IP: users behind congested routes, operators comparing transit paths, and anyone testing how anycast routing behaves from a particular access network. The README also lists a long set of prohibited use categories, including VPN and proxy content, downloading sites, and anything that interferes with Cloudflare's operation. Whatever your view of that list, it signals the author's intent that the tool be used for measurement rather than for building a bypass service.

How the scan pipeline works: random sampling, RTT, then serial speed

The README describes three stages, and the ordering is the interesting design decision. First, IPs are randomly generated from the subnet list. For IPv4 the first three octets are kept and the last is randomized; for IPv6 the first three segments are kept and the last five are randomized. This means the tool never enumerates a range exhaustively. It samples. Second, an RTT test runs concurrent TCP handshakes plus an HTTP GET, verifies the CF-RAY response header to confirm the address really is a Cloudflare edge, averages three attempts, and sorts the candidates by ascending latency. Third, the speed test runs serially: it downloads a test file from each candidate in turn, computes an instantaneous peak using a one-second sliding window, and stops at the first IP that reaches the configured bandwidth target. That last detail is the core of the tool's cost model. Because the speed stage is serial rather than parallel, a scan finishes faster when an early candidate is good and slower when none of them reach the target, in which case the whole candidate list gets downloaded from. The RTT stage is cheap and parallel; the speed stage is expensive and sequential. If you are scanning a large custom range, that asymmetry is what determines how long you wait.

Building and running better-cloudflare-ip with Go 1.22

The README requires Go 1.22 or newer and gives two ways to start. The first compiles a binary and runs it in one line. The second skips the build step. Both launch an interactive menu rather than a command-line-flag interface, so there is nothing to script out of the box unless you drive stdin yourself.

go build -o better-cloudflare-ip . && ./better-cloudflare-ip

If you would rather not produce a binary, the README offers the direct route.

go run main.go

On launch you get the numbered menu: IPv4 optimization with TLS, IPv4 without TLS, IPv6 with TLS, IPv6 without TLS, single-IP speed test with and without TLS, clear cache, and update data. Choosing the first entry starts the full three-stage pipeline for IPv4 over TLS, and the program prints candidates as it ranks them before settling on a result. The single-IP speed test is the useful one when you already have an address in mind and only want a number for it.

Custom ranges live in ips-v4.txt and ips-v6.txt. The README specifies the accepted formats: x.x.x.x or CIDR for IPv4, and x:x:x:x:x:x:x:x or CIDR for IPv6, with `::` compression expanded automatically. Only the first three segments of each entry are honored; the rest are randomized at scan time. The README warns explicitly that using the update data entry overwrites your local custom files, so keep a copy elsewhere before you update.

The limitations you should weigh before adopting it

The most consequential limitation is stated plainly in the README's data security section: this version does not require users to upload any data to a server, and the server only maintains and distributes the IP pool. That is a privacy property, but it also means the tool has no server-side measurement, no historical database, and no cross-user comparison. Every result is local and perishable. A scan run this morning can be wrong this evening, because anycast routing and transit congestion change. There is no caching strategy described that would make yesterday's answer trustworthy today; the clear cache entry exists, but the README does not document how long entries live or when they are invalidated. Second, the speed stage's stop-at-first-target behavior means the reported result is the first IP that met your threshold, not the fastest one in the pool. If you set the target low, you will get a fast-enough answer quickly and never learn whether a better one existed. Third, the randomization strategy means the tool may never probe the specific address you care about. If you want to evaluate a known IP, use the single-IP speed test rather than the range optimization entries. Fourth, the repository has no documented licence. The README contains a use declaration and a list of prohibited categories, but a use declaration is not a licence grant, and the repository metadata shows no licence identifier. That ambiguity is a real obstacle for anyone planning to bundle or redistribute the code.

How it differs from Cloudflare's own speed test and from DNS-based approaches

The obvious alternative is Cloudflare's own speed test page, which measures your connection to Cloudflare's network and reports latency and throughput. The difference is in what gets measured. The speed test page measures the path Cloudflare assigns you; better-cloudflare-ip measures many candidate edge addresses and ranks them, which is the point when your assigned path is the problem. The second common alternative is simply using a public list of Cloudflare IPs, which is what the related searches around IP lists suggest people look for. A static list tells you which addresses exist; it says nothing about which one is fast from your location, and it goes stale as Cloudflare's announcements change. better-cloudflare-ip consumes such a list as input and adds measurement. A third approach is DNS-based selection, where a resolver returns whichever edge is nearest according to its own view. That is zero-effort and works for most people, but the resolver's notion of nearest is based on its own network position, not yours, and it offers no way to compare alternatives. better-cloudflare-ip is the manual, evidence-producing option in that set. It is more work and it produces a number you have to act on yourself.

Maintenance, releases, and what the licence silence means

The repository is not archived, and the last push was on 2026-05-25, which coincides with the 20260525 release described as a new Go version. Before that, the 20251119 release fixed shell latency calculation, and the 20220615 release added and removed things. So the project has moved from a shell implementation to Go, with the most recent work landing in the Go rewrite. That is a meaningful upgrade consideration: the Go version is the current line, and the older shell-based approach is superseded. For ongoing cost, the tool has no runtime dependencies described beyond the Go toolchain itself, no server to run, and no configuration file beyond the IP lists. Upgrading means pulling the repository and rebuilding, then re-checking any local edits to ips-v4.txt and ips-v6.txt, since the update data entry overwrites them. On licensing, the README does not state a licence and the repository metadata gives none. The README's use declaration restricts use to study and lists prohibited categories, but it does not grant rights the way a recognized licence does. If you intend to use this inside a commercial product or redistribute a modified copy, that gap is something to resolve with the author rather than assume away. Nothing here constitutes legal advice.

Editorial conclusion

Adopt better-cloudflare-ip if you already maintain your own list of Cloudflare edge IPs and want a local, upload-free way to rank them from your own connection. Do not adopt it if you expect a DNS resolver, a hosted service, or a tool that changes which IP your client uses: the README states the server only maintains and distributes the IP pool, and the program itself does not configure your system. Before relying on it, verify that your Go toolchain is 1.22 or newer, confirm that the ips-v4.txt and ips-v6.txt files you edit will not be overwritten by the update data menu entry, and check whether the repository has published a licence file at all, because the README does not state one.

Frequently asked questions

Official sources

1. badafans/better-cloudflare-ip on GitHub
2. Issues
3. README
4. Releases