Proxy Checker v6.3: a self-hosted proxy checker for your own server

The problem Proxy Checker solves: your server, not someone else's

Public proxy lists are long and stale. The usual workflow is to copy a list into a file, deduplicate it by hand, and try entries one at a time until something responds. That tells you a proxy answered. It does not tell you whether the machine you are about to route traffic through can reach the proxy at all.

The README frames the whole project around one chain: your checking server to the proxy IP to the target service. A proxy that a stranger's server reports as working may be unreachable from your host, and the reverse happens too. So the project's answer is to run the checker on the box that needs the proxies. The README states this directly: whoever will use the proxy should do the testing, because that result is the one with reference value.

The intended user is someone running scripts, account servers or API connectivity checks who wants a maintained pool rather than a one-off list. The README names these cases: pulling usable proxies from public sources without manual copying, knowing whether a proxy is useful from the current server, distinguishing plain connectivity from web reachability, API domain reachability, Cloudflare status, exit IP, country and IP type, and keeping a personal repo that can be filtered, retested, copied and exported as a stable link.

How the detection pipeline works, from fetch to TXT link

The repository is a self-hosted Python service with a browser front end. Top-level files are server.py, proxy_check.py, fetch_proxies.py, config.json, index.html, login.html, app.js, plus api/ and tools/ directories. The single runtime dependency in requirements.txt is curl_cffi>=0.14.0, which the project uses for its HTTP client.

Data flows in one direction. fetch_proxies.py pulls from the bundled public sources: Proxifly, Databay, IPLocate, OpenProxyList/Roosterkid, TheSpeedX, VPSLab, Hookzof, Spys.me, ProxyScrape, GeoNode and My-Proxy, with ProxyNova, hide.mn, free-proxy-list and CheckerProxy kept conservatively. The front end can pull one source or all of them, deduplicated by proxy address. The README says aggregate size usually reaches 10,000 or more, and that quality still depends on your own results.

proxy_check.py then runs the checks. Five modes exist: generic, openai, grok, gemini and claude. The specialized modes test the service home page, the API domain and Cloudflare status. An HTTP 401 or 403 from an API endpoint is recorded as API domain reachable, because the network path reached the server; the README is explicit that this says nothing about whether an account, key or quota works. Cloudflare status only affects the web-access judgement and is not used to mark API reachability as failed.

Results carry a grade A/B/C/D/F, a stability flag and a recommended use such as basic proxy, web usable, API usable, or web plus API. Exit IP, country and IP type are recorded so you are not left staring at an HTTP 200 with no idea where traffic actually exits. Anything you add goes into a repo that is served as a public TXT link for subscriptions and a JSON link that keeps grade, country, purpose and service reachability.

Running Proxy Checker on your own machine

The README does not print a full install command list, so the safe path is the repository layout plus requirements.txt. Clone the repo, install the one declared dependency, and start the server module. The README states the public default port is 8888.

pip install -r requirements.txt
python server.py

After that, open the web UI at port 8888 on the host. The README gives the default password as linux.do and advises changing it immediately after going live. Login state uses an HttpOnly cookie, and on a same-origin self-hosted deployment the login page is served without the main interface HTML or app.js until you authenticate.

A first real use is to pull all free proxy sources and run a batch check. The README describes one-click fetching of every built-in source with deduplication by address, then manual detection with configurable rounds and concurrency. Detection rounds default to 2 with a ceiling of 3, and the concurrency value you submit as max_concurrent is applied by the backend to both an asyncio.Semaphore and the HTTP client connection count.

{
  "rounds": 2,
  "max_concurrent": 100
}

The keys above are the ones the README names for the settings dialog: detection rounds, concurrency, request timeout, protocol-detection timeout, login validity, log retention, default timezone and login password. The README does not document the full key set of config.json, so check the file itself before editing it. Once results appear, you add individual proxies to your repo, and the repo syncs to the cloud TXT and JSON links.

Background tasks, and why Vercel cannot host them

The auto task is a backend scheduler, not a browser timer. The README contrasts it with a setInterval approach: with the browser closed, the service still pulls all free proxy sources on schedule, merges the proxies already in your repo, runs batch checks at the configured rounds, concurrency and mode, and syncs results that match your policy to the repo links.

Scheduling supports an interval of every N hours or a fixed HH:MM daily run in a chosen timezone. You can check only new proxies or force a full recheck. Three ingestion policies are named: stable_only, include_unstable and archive_all. Retest-based cleanup is on by default, meaning old repo proxies that take part in the round and fail are removed, while a task that errors out as a whole will not wrongly delete the old repo. While an auto task runs, manual detection is blocked so one server is not hit by two concurrent batches.

The constraint is deployment shape. The README states Vercel and serverless platforms cannot run a resident background task, and the UI shows an explicit not-supported message there. If scheduled checking is the reason you are interested, you need a host that keeps a process alive.

v6.3 fixed a specific failure mode in this area: large batches could stall on the last few proxies and never finish. The fix replaced creating all async tasks at once with a fixed-size worker queue, added a per-proxy hard timeout that records an F-grade failure and moves on, and made stop cancel unfinished workers instead of sitting in stopping. The task summary now includes last_progress_at.

What Proxy Checker deliberately refuses to claim

Version 6.0 removed registration-page detection, and the reasoning in the README is worth taking at face value: opening a registration page does not mean registration will succeed, because risk controls, phone numbers, email, browser environment, history and regional policy all matter. Judging that from an HTTP status would mislead. The tool now limits itself to whether the proxy works from this server and whether the target page or API is reachable.

The Cloudflare wording was tightened for the same reason. What used to be described as CF bypass is now labelled as the web page not being intercepted by Cloudflare, and the hover text states that this only means the page did not meet a Cloudflare challenge this time, with no guarantee for registration, login, Auth0 or other account flows. The failure-side filter was renamed to web CF intercepted. That is a narrower promise than the label suggests at a glance, and the README acknowledges the earlier wording was less accurate.

There is also an operational limit. A 401 or 403 from an API domain counts as reachable, so a repo full of API-reachable proxies tells you nothing about credentials or quota. And because checking is local by design, results are not portable: a repo built on one host is a statement about that host's routes. The README does not document rollback for a repo that an auto task has already updated, so treat the JSON export as your backup mechanism.

Proxy Checker compared with a hosted proxy checker online

A hosted proxy checker online, or a browser extension, runs the test from the vendor's infrastructure and hands you a list. The difference is where the socket is opened. If your goal is to pick proxies for a scraper running on that same vendor's network, a hosted checker is fine and costs you nothing to operate. If your goal is to route a process on your own VPS, the hosted result answers a question about a different machine.

Proxy Checker inverts that. You pay in setup and in keeping a Python process alive, and you get a result scoped to your host, plus a repo you control that other programs can pull from a stable TXT or JSON URL. The README's framing of the chain, your server to the proxy to the target, is the whole distinction. A hosted checker also tends to be a snapshot; Proxy Checker's auto task is designed to keep re-testing on a schedule and prune failures, which is a different product shape from a one-off online test.

IPRoyal is a paid proxy provider rather than a comparable self-hosted checker, so it is not an alternative here. If you want a hosted, zero-install test, use one of those. If you want a maintained pool tied to your own network position, that is what this project is for.

Licence, maintenance and the upgrade cost you should budget for

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. The repository contains a LICENSE file at the top level. That is the licence text; it is not legal advice, and if you redistribute a modified version you should read the file rather than this summary.

The repository is not archived. The last push was on 2026-07-12, which is the same date as the v6.3 release, so the project is not currently abandoned but has also not received a push in roughly two months. Releases show a steady cadence before that: v6.1 and v6.2 both landed on 2026-06-15, and v6.3 on 2026-07-12.

Upgrade cost is low in dependency terms, since requirements.txt pins a single package, curl_cffi>=0.14.0. The real cost is state. The changelog for v6.1 to v6.2 lists fixes for repo data being overwritten by stale browser local state, a base_count check that rejects a save when the cloud repo has moved on, and removal of the fallback to a public default repo that could mix data between user tokens. Those are the kinds of bugs that appear when a browser cache and a server-side repo disagree. If you run auto tasks and also edit the repo from the UI, export JSON before upgrading and confirm the repo count in the UI matches the TXT and JSON links afterwards.

Editorial conclusion

Adopt Proxy Checker if the machine doing the checking is the machine that will use the proxies, and you want a background job that keeps a repo current without a browser open. Skip it if you need a hosted proxy checker online, a browser extension, or a check of whether an account can actually register through a proxy. Before relying on it, open config.json and confirm the default port 8888 and the default password linux.do match your deployment, then change the password.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. strongshuai/proxy-checker on GitHub