What the June 11 Snapshot Found#
This benchmark compared 2,911 entries captured from seven provider-published free proxy lists on June 11, 2026. Each fixed IP:port snapshot was tested in three rounds from one runner. Across the three rounds, Databay's list had the highest average availability in this sample at 63.9%, followed by ProxyScrape at 36.7%. The remaining lists averaged between 2.5% and 20.3%.
Those figures describe one dated snapshot, not a permanent ranking or a promise about what a reader will receive later. Public relays change quickly, and a different capture time, runner location, destination, timeout, or scoring rule can change the order. Databay also operated the benchmark and was one of the compared sources. The frozen inputs, harness, raw round files, and aggregation code are published in the free-proxy-list-benchmark repository so readers can inspect the exact run rather than relying on the headline.
| List | Entries | Alive | HTTPS | Amazon | Median latency | |
|---|---|---|---|---|---|---|
| databay.com | 497 | 63.9% | 36.9% | 32.4% | 16.8% | 1,067 ms |
| proxyscrape.com | 500 | 36.7% | 23.5% | 17.5% | 9.9% | 1,825 ms |
| floppydata.com | 314 | 20.3% | 15.3% | 11.9% | 3.8% | 1,220 ms |
| proxiware.com | 500 | 12.9% | 5.8% | 3.8% | 1.6% | 1,320 ms |
| nodemaven.com | 500 | 7.7% | 3.8% | 2.5% | 1.5% | 2,214 ms |
| roundproxies.com | 100 | 4.7% | 3.0% | 2.3% | 1.7% | 2,442 ms |
| geonode.com | 500 | 2.5% | 1.8% | 1.6% | 0.9% | 2,160 ms |
The Published Inputs and Run Window#
The committed snapshot contains 497 Databay entries, 500 ProxyScrape entries, 500 Geonode entries, 314 FloppyData entries, 100 RoundProxies entries, 500 NodeMaven entries, and 500 Proxiware entries. The loader removes duplicate IP:port entries within each source before testing. Protocol labels come from the source files: HTTP, HTTPS, SOCKS4, or SOCKS5.
The run metadata records a start at 02:29:01 UTC and completion at 02:53:11 UTC on June 11. The three probe rounds began at 02:36:06, 02:44:38, and 02:53:11 UTC. All 2,911 entries appear once in each raw round file. Holding the input fixed across rounds lets the report distinguish initial availability from short-window persistence.
The repository does not include the separate collection program that fetched each provider's list. It does include the captured list files and source descriptions. This means readers can verify exactly what was tested and recalculate the results, while the claim that every provider snapshot represented its freshest possible output still depends on the documented collection process.
How Each Endpoint Was Tested#
A relay was marked alive when it completed at least one of the benchmark's basic HTTP or HTTPS reachability checks. HTTPS capability records whether the route completed a TLS tunnel. The Google check required https://www.google.com/generate_204 to return HTTP 204; the Amazon check required https://www.amazon.com/robots.txt to return HTTP 200. Latency is the fastest successful round trip recorded for an alive result.
The harness also compared the observed exit address with the runner's public address. A separate best-effort HTTP header reflection check classified results as elite, anonymous, transparent, or unknown. That classification is less complete than the reachability metrics because many free relays could not reach the reflection service before the deadline.
A successful control request proves only that the relay completed that specific request at that time. It does not prove authorization, account safety, browser compatibility, destination acceptance, or access to another host. A failed Google or Amazon check can reflect relay failure, protocol handling, rate limiting, destination policy, or a transient network error.
Availability Across Three Rounds#
Databay's 497-entry snapshot returned 320, 315, and 318 alive results across the three rounds: 64.4%, 63.4%, and 64.0%. ProxyScrape returned 191, 171, and 188 alive results from 500 entries. FloppyData returned 64, 67, and 60 from 314.
The largest short-window change was NodeMaven: 81 of 500 entries were alive in round one, followed by 15 and 20. The benchmark's stability metric asks what share of round-one survivors remained alive in every round. On that definition, Databay recorded 73.4%, FloppyData 64.1%, Proxiware 55.7%, ProxyScrape 46.1%, RoundProxies 33.3%, Geonode 28.6%, and NodeMaven 16.0%. Small survivor counts make the lower-volume percentages especially uncertain.

The Composite Score Is a Chosen Summary, Not Ground Truth#
The repository calculates a 0–100 composite using 30% availability, 20% Google, 15% Amazon, 10% HTTPS, 10% IP-hidden, and 15% latency. Latency falls linearly from a score of one at zero milliseconds to zero at 5,000 milliseconds. On those weights, the published scores are Databay 50.0, ProxyScrape 31.5, FloppyData 23.9, Proxiware 17.8, NodeMaven 12.6, RoundProxies 10.6, and Geonode 10.1.
The weights express one preference: basic reliability first, followed by two destination checks. A reader who cares primarily about SOCKS support, a specific geography, or a different destination should not use that composite unchanged. The raw metrics are more informative than the rank, and the aggregation code deliberately keeps the weights in one editable definition.

Overlap Does Not Explain Quality by Itself#
The report calculates Jaccard overlap between source snapshots. Geonode and Proxiware had the largest measured overlap at 0.322, representing 243 shared IP:port entries. Geonode and RoundProxies followed at 0.200 with 100 shared entries. Databay and ProxyScrape overlapped at 0.126 with 106 entries, while most source pairs were below 0.10.
Overlap shows that providers sometimes publish the same public endpoints. It does not establish why one list performed better. Collection timing, checking cadence, protocol labels, source selection, and relay churn can all affect both overlap and availability. The data supports reporting the shared counts; it does not support claiming that overlap caused failure or that a low-overlap list necessarily came from a superior pipeline.
Recalculate the Report From the Repository#
The repository separates inputs, observations, and outputs. The lists/ directory holds the fixed provider snapshots. results/proxies.json records the loaded endpoint set. results/raw/round_1.jsonl through round_3.jsonl contain endpoint-level observations. results/run_meta.json records timestamps and probe configuration. The analyzer produces summary.csv, per_round.csv, report.md, and charts from those raw rows.
Install the declared Python dependencies, then run python analyze_results.py --in results to regenerate the aggregate report without making new proxy requests. Running python run_benchmark.py probes the committed endpoints again, but a later network run should be treated as a new observation because public relays and destination behavior change. Preserve the commit hash, UTC time, runner region, dependency versions, and output manifest when comparing runs.
Safety, Ethics, and Study Limits#
Free proxies are operated by unknown parties. Do not send passwords, payment data, private documents, session cookies, or other sensitive information through them. HTTPS protects content between a correctly validated client and destination, but an untrusted route can still log connection metadata, fail unpredictably, redirect plain HTTP, or present a certificate error that must never be ignored.
This study has several limits: one capture date, one runner region, a short three-round window, unequal source sizes, source-supplied protocol labels, incomplete header-reflection coverage, and a composite designed by Databay. Databay's list was evaluated by Databay, creating a commercial conflict even though the inputs and calculations are public. No result authorizes requests to a third-party site or predicts that site's future treatment.
Use this benchmark as a dated reliability sample and a reusable measurement method. For operational work, prefer an official API, feed, or controlled proxy service with documented ownership, authentication, support, and acceptable-use terms.
