watchttvv free-proxy-list: hourly scrapes of one page, with nothing verified

The project says what it is: a scrape of one other page

The introduction is unusually honest for a list of this kind, and the honesty is the most useful thing in the README.

The author describes finding a public web page for proxies, noticing that it updated fairly quickly, and scraping it. The page is named in the documentation, and the author goes further and points readers at it directly, saying it is the more complete one and inviting anyone interested to go and scrape it themselves.

That single sentence settles the architecture. This repository is not a crawler discovering open proxies by probing hosts, and it is not a checker validating what it finds. It is a scheduled fetch of a page that somebody else maintains, followed by a reformat.

The quality claim is made in the same breath, and it is a claim about proportion rather than a measurement. The author contrasts it with the kind of list where you have ten thousand entries and only a few work, and says these are mostly usable. That is a statement about the source page's curation, not about anything this repository verifies.

So the useful way to read the project is as a small, frequently-refreshed convenience wrapper around a list you could fetch yourself, with a fixed format and a location annotation attached.

Two dependencies, and both of them are for parsing HTML

The dependency list is the confirmation that the mechanism is a page fetch rather than a probe.

There are two entries and the requirements file pins a minimum version for each: an HTTP client at version 2.28 or newer, and an HTML parsing library at 4.11 or newer.

Neither is a proxy testing library, a concurrency framework, a scheduler, or a geolocation database. There is nothing in the list that could open a connection to a candidate address and check whether it forwards traffic.

That is a coherent design for what the script does, and it has a real upside. A probing script needs to handle thousands of timeouts, needs retry logic, needs to distinguish a refused connection from a slow one, and ends up with a much larger dependency surface and a much longer runtime. A scraper is a fetch and a regular expression, and it finishes in seconds.

The upside is also exactly the limitation. Whatever quality the source page has is the quality you get, and whatever the source page gets wrong, this list repeats without noticing. The geolocation annotation in the output is copied from that page rather than resolved independently, which is why the annotation can be wrong for an address that works perfectly well.

One line per proxy, with the location in brackets

The output format is fixed and documented with three examples, which is more than a project of this size needs but makes the data trivially parseable.

Each line is a protocol scheme, then the address and port, then a bracketed location. The scheme is either a SOCKS5 or an HTTP prefix, the separator between scheme and address is a double colon, and the address and port are separated by a single colon. The location is appended in square brackets after a space.

The three samples in the documentation are a SOCKS5 entry labelled as California in the United States, an HTTP entry labelled as Seoul, and a SOCKS5 entry labelled as Quebec in Canada. The labels are written in the source project's own language, so a consumer that wants to group by country has to deal with non-ASCII text in that field rather than a two-letter code.

That is a real limitation for anyone planning to filter by geography, since the useful part of the annotation, the country, is not separated from the city and region by any delimiter. Grouping by country means matching on a prefix of a bracket string, which works while the labels stay in one language and stops working the moment they do not.

The plain text file is the only output. There is no JSON, no CSV, and no per-country or per-protocol shard.

The hourly job means the commit history is the update log

Automation is handled by a scheduled workflow rather than by a long-running process, and the choice has a visible consequence.

The project runs its generator once an hour, automatically commits the updated list, and describes the point of that as keeping the proxy information current in real time.

So the repository is a data file plus a script, and the file's history is the audit trail. Every hour produces either a commit with new content or no commit at all, which means the age of any given entry is recoverable from the log even though the file itself carries no timestamp.

The same design means there is no server to run. You clone the repository or fetch the raw file, and there is nothing to keep alive. That is a genuine advantage over the common pattern of a proxy list served from a site that may or may not be up when you need it.

The manual path is one command, for anyone who wants to refresh locally instead of waiting for the next scheduled run:

python generate_proxy_list.py

The result overwrites the text file in the working directory. Nothing in the documentation describes a retry, a timeout, or what happens when the source page is unreachable, which is the question to keep in mind: a failed fetch on a quiet path looks the same as a day with no new working proxies.

A disclaimer and no licence, which is an odd combination

The closing section is a short disclaimer, and the repository's licensing position is worth naming next to it.

The disclaimer states that the project is for study and research purposes only, and asks users to comply with relevant laws and the terms of the websites involved. That is a reasonable position to state and not the same as a grant of anything.

There is no licence file among the repository entries. The visible files are the workflow directory, the README, the generator script, the proxy list itself, and the requirements file.

So the terms are: free to read, no grant to reuse, modify or redistribute. For a text file of scraped addresses that is a mild gap, since copying it elsewhere is not something the terms prohibit and not something they permit either. The generator script is in the same position.

The dependency versions are also worth a glance before running the script yourself, because they are minimums rather than exact pins, so an install will take whatever the current release of each library is. That is normal for a two-line requirements file and worth knowing if you care about reproducibility.

Editorial conclusion

This list fits someone who wants a small, recently-touched set of open proxies to try, and who values knowing exactly where the data came from over having a large pool. Leave it if you need verified endpoints, since the documented mechanism is a page scrape and no checking step is described, and leave it if you need a supply you can depend on, because the whole list disappears if the source page changes. Verify first that the addresses in the file still respond before you route anything through them, and read the geolocation annotation as decoration rather than as a fact about the address, since it is copied from the source page rather than looked up.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases