ProxyScrape free-proxy-list: the headline says 22,000, the stats block says 3,071

The description and the stats block disagree by a factor of seven

The first thing to reconcile is the size of the list, because the two places that state it do not match.

The repository description says roughly twenty-two thousand proxies across more than ninety countries. The statistics block embedded in the README, which is labelled as generated by a script and not to be edited by hand, reports a total of 3,071: 655 HTTP, 203 HTTPS, 292 SOCKS4, 2,124 SOCKS5, across 88 countries and 219 shards. The feature list above it says over two hundred shards across about a hundred countries.

The generated block carries a timestamp, which is the tell. The description has no timestamp and is maintained by hand alongside other metadata, so the reasonable reading is that it reflects an earlier state of the upstream API or a different, larger collection, while the block reflects the current list.

So the number to quote is the smaller one, and the way to quote it is to read the block. That is not a criticism so much as a warning: for a resource that changes every five minutes, no number written into a repository description is going to stay true, and this one is already about seven times out.

The protocol mix is lopsided, and the HTTPS shard is the smallest

The per-protocol counts in the generated table are the second thing worth reading, because they decide which shard you should actually pull.

SOCKS5 accounts for 2,124 of 3,071 entries, which is roughly two thirds of the whole list. HTTP accounts for 655 and SOCKS4 for 292. The HTTPS shard is the smallest at 203, which is a little under seven percent of the total.

That last number surprises people, because HTTPS is the first thing anyone asks for. The layout section explains what the shard actually is: it is not a distinct protocol but the HTTP protocol with the TLS flag set, which is what makes a connection tunnel-capable. So the HTTPS shard is a filtered view of the HTTP population rather than an independent supply, and it is small because most of the open HTTP proxies in the wild do not do CONNECT.

The consequence for a consumer is straightforward. If you need tunnel capability, the HTTPS shard at 203 is your real candidate pool and it will not grow much. If you just need to vary the source address for plain requests, the SOCKS5 shard gives you the largest pool by a wide margin. The United States shard, listed separately in the download table at 275 entries, is similarly modest.

An empty shard returns not found, on purpose

There is one design decision here that will break a naive client, and it is stated in the feature list rather than buried.

The list is described as deduplicated and self-cleaning, unique on the triple of protocol, address and port. And empty shards return a not-found response rather than serving stale data.

Both halves of that are deliberate. Deduplication on that triple means a proxy appearing in several sweeps collapses to one entry, so the count is of distinct endpoints rather than of observations. And returning nothing rather than an old file means the shard directory is a truthful reflection of what is live right now, rather than a mirror of what was live whenever the file was last written.

The cost is on the consumer. Code that fetches a shard, parses the body, and iterates the lines will not distinguish a not-found from a parse failure unless it checks the status. A pipeline that assumes three hundred lines because it read them once will start reporting zero proxies for a region that simply has none at that moment, and will look like a bug in the list rather than a correct empty answer.

The Telegram channel the project points at is the escape hatch for the impatient case, described as a daily post that refreshes itself through the day, plus an on-demand bot that will produce a list for a protocol and country on request.

Every entry carries enough metadata to filter before connecting

The field list is the reason to use this mirror rather than a bare list of address and port pairs.

Each entry ships with the protocol, the address and port, the country and its code, the city, an anonymity level, a flag for whether TLS is available, an uptime percentage, the autonomous system number, the internet service provider, a latency figure in milliseconds, and a last-checked timestamp.

That set changes what you can do with a list. Sorting by latency and taking the first twenty is a different operation from taking the first twenty, and filtering to a country and an operator before connecting is possible at all. The uptime percentage and the last-checked timestamp together are what let you distinguish an endpoint that has been stable for days from one that was seen once an hour ago.

Two caveats are worth stating. Anonymity level and uptime are the provider's characterisation, measured from outside, so they inherit whatever the measuring vantage point can see. And latency in milliseconds measured from the scraper's location is not the latency you will see, which is the failure mode that catches people who sort on that column without reading what it means.

The three formats serve the same data: one file per line with a protocol-prefixed address and port, one JSON array of objects, and one CSV with the metadata columns. All three are served over a CDN, and there is a typed client library published alongside.

The repository is five minutes stale by design, and the API is faster

Two different update cadences, and the project is explicit about which one to use when.

Everything is fetched from a CDN path that addresses the main branch, so there is nothing to resolve first:

curl https://cdn.jsdelivr.net/gh/proxyscrape/free-proxy-list@main/proxies/all/data.txt

Swap the shard path for a single protocol, such as the HTTP one, or for a country directory, to narrow the pull without filtering on the client.

The repository refreshes every five minutes, and the README attributes that to a dedicated server-side cron rather than to a best-effort workflow run. The distinction matters more than it sounds: a workflow-based refresh depends on someone else's runners and is throttled by their queue, whereas a cron on the publisher's own machine is not. The comment about not being a best-effort action is a response to the failure mode of the previous approach.

The hosted API is stated to update every minute, and the README says plainly to use whichever fits your workflow. So if you are polling from a running process, the API is the fresher source by a factor of five, and the repository is the better choice when you want a stable, cdn-cached artefact that you can pin a build against.

Everything is served through a CDN pointed at the main branch rather than at a tag, which is consistent with a resource that has no releases at all. The repository publishes no tagged versions, so pinning means pinning a commit, and the branch moves underneath you.

The rest of the repository is small: a proxies directory holding the shards, a scripts directory containing the update script, and a workflow directory. The primary language is recorded as Python, and the licence is MIT, so the format of the data and the code producing it are both yours to reuse.

Editorial conclusion

This list fits a scraper or a test harness that needs a rotating pool of open proxies with enough metadata to filter by, since the per-entry fields let you sort by latency, uptime, country or network operator before you connect rather than after. Leave it if you need authenticated proxies, because nothing in the schema carries a username or password, which is also the most common thing people search for and do not get here. Verify first the live count from the statistics block rather than the repository description, and be ready for a shard to return a not-found response when its set is empty, which is a deliberate choice that will break a client which assumes a file is always there.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository