Proxy Checker
How to test any proxy endpoint with the free checker, what each result means, and why the latency it reports matters more than the raw speed.
Last updated
The Proxy Checker is at /tools/proxy-checker. It connects through an endpoint you supply and reports whether it works and what it costs you.
It is provider-agnostic: it will test any HTTP or SOCKS5 endpoint, ours or anyone else's.
The inputs
| Field | What to enter |
|---|---|
| Proxy host | The hostname or address of the proxy |
| Port | The port the proxy listens on |
| Protocol | HTTP or SOCKS5, matching how the endpoint speaks |
| Username and password | Required for endpoints that authenticate |
For a generated LightningBytes endpoint, all of these come straight from the results table: the Hostname, Port and Protocol columns, plus the sub-user credentials. See Generating Proxy Endpoints.
What it reports
| Result | Meaning |
|---|---|
| Working | The connection succeeded and a response came back |
| Exit IP | The address the proxy presented to the destination |
| Connect time | How long establishing the connection took |
| Latency | The extra delay the proxy adds, compared with a direct request |
Why latency is the number to watch
Bandwidth and raw speed are rarely the limiting factor in collection work. Latency is, because it sets how many sequential requests you can make per minute.
Two figures describe it:
Connect time. The cost of getting through the proxy at all.
Extra latency. The delay the proxy adds over a direct connection. This is the number to compare when choosing between endpoints, because it is what a target sees as slowness.
An endpoint with a very high added latency will time out on strict targets even though it is technically working. If a job is failing with timeouts, checking the endpoint is the first diagnostic step.
Confirming the exit address
The Exit IP is what the destination saw. Two follow-ups tell you whether it is the address you wanted:
- Compare it with the address the generator assigned, if you are testing a specific endpoint.
- Look it up with IP Lookup to see which country and city it resolves to.
An endpoint can be working perfectly while presenting an address in the wrong place. The checker answers "does it work"; the lookup answers "where is it".
Testing before you commit
Three uses worth adopting.
Before a large run. Check one endpoint from the set. If it fails, the problem is upstream of your code and it is cheaper to find now.
After generating. If Proxy checking is set to Manual in My Account, the generator will not check for you, so this is where that check happens.
When a job breaks. Test the endpoint on its own. If the endpoint works, the problem is in the client; if it does not, the endpoint is the problem. That single test halves the search space.