Batch Proxy Checker · Dev Tools

About Batch Proxy Checker

Batch Proxy Checker takes a list of up to 100 HTTP, HTTPS, or SOCKS5 proxies, connects through each one to a target URL you choose, and reports what happened at every stage: whether the proxy accepted a TCP connection, whether authentication succeeded, whether a tunnel was established, whether TLS verified, and what status the target returned. Working and failing entries can be copied back out as two lists.

A proxy that answers on its port is not a proxy that works. Between the first packet and a usable response there are five or six independent things that can go wrong, and from outside they look identical: a connection that hangs, a wrong password, a handshake the server does not support, a name the proxy cannot resolve, a target that refuses the exit address. Testing by hand collapses all of that into works or does not, which tells you nothing about whether the credentials are stale, the provider is down, or the destination blocks that range. The stage where a check stopped is the most useful field in the result.

How to use this developer tool

Paste one proxy per line. Both the URL form (http://user:pass@host:port, socks5://host:port) and the colon-separated form (host:port:user:pass) are accepted, and exact duplicates are removed.
Set the target URL to something you are entitled to request that returns a small, predictable response. A trace or IP echo endpoint is ideal because it also shows which exit the request arrived from.
Start the batch. Five entries are checked at a time, so the run stays orderly and the proxies are not hammered.
Read each row's summary — connected, authenticated, HTTP status — and open the details only for rows that failed.
In the details, go straight to the failure stage and the failed hop; those two fields say which layer to fix, and the detail below them is the upstream's own message.
Copy the successful list into your configuration and keep the failed list for a retry, since proxy availability is frequently temporary.

Worked example: three proxies, three outcomes

A typical batch off a provider dashboard. One entry works, one has stale credentials, and one is not listening — and each failure names the stage it reached.

Proxy list

http://demo:s3cret@203.0.113.9:8080
socks5://198.51.100.20:1080
192.0.2.77:3128:demo:s3cret

Results

203.0.113.9:8080 — success
  Connected · Authenticated · HTTP 200
  Proxy scheme      http_connect
  Target            https://example.com
  Response time     412 ms
  Target IP         203.0.113.9 · IPv4
  TCP connected     yes    Tunnel established  yes    TLS verified  yes

198.51.100.20:1080 — success
  Connected · No authentication required · HTTP 200
  Proxy scheme      socks5
  Response time     780 ms

192.0.2.77:3128 — failed
  Failure code      PROXY_CHECK_FAILED
  Failure stage     Proxy authentication
  Failed hop        192.0.2.77:3128
  Detail            proxy returned 407 Proxy Authentication Required

The third entry is the interesting one. TCP connected and the proxy answered, so the host and port are right and the service is alive — only the credentials are wrong or expired. Had it failed at the first-hop TCP stage, the host and port would have been the thing to check. Same symptom, completely different fix.

Failure stages and what each one implicates

Reading the stage before the error message turns a list of dead proxies into a list of specific, fixable problems.

Stage	What was being attempted	What a failure here means
validation	Parsing the line you pasted	The address never left the tool: a wrong scheme, a missing port, or a password without a username. Nothing was contacted.
first_hop_dns	Resolving the proxy's own hostname	The proxy is written as a name that does not resolve. Use the literal address or fix the record — the proxy was never reached.
first_hop_tcp	Opening a TCP connection to the proxy	Nothing is listening, a firewall dropped it, or the port is wrong. Also what you see when a provider allow-lists client addresses and ours is not on the list.
proxy_auth	Authenticating to the proxy	The service is alive and rejected the credentials — HTTP 407 or a refused SOCKS5 authentication. Host and port are correct; the username or password is not.
proxy_chain	Negotiating through a chain of hops	An intermediate hop failed. The failed-hop field names which one, so you can test it on its own.
target_connect	Reaching the target through the proxy	The proxy accepted you and could not reach the destination: a name it cannot resolve, a blocked port, or a destination filter on its egress.
request	Sending the request and reading the response	The tunnel worked and the exchange failed — a TLS problem, a truncated response, or a target that closed the connection.

Troubleshooting

A proxy works in your browser but fails here at the first TCP stage.

Why it happens Most commercial proxies authorise by client IP address. Your machine is on the provider's allow-list; this site's server is not, so the connection is refused before authentication is attempted.

Fix Switch that proxy to username and password authentication for the test, or test from a machine on the allow-list. An IP-authorised proxy fundamentally cannot be checked by a remote service.

Every entry fails at the validation stage.

Why it happens The list is in a format the parser does not recognise — quotes and trailing commas copied out of JSON, an unsupported scheme such as socks4, or four colon-separated fields in an unexpected order.

Fix Normalise the list first. The Proxy Formatter converts between the common layouts; supported schemes are http, https, socks5, and socks5h, and the colon form expects host:port:user:pass.

The proxy connects and authenticates, but the target returns 403.

Why it happens The destination is blocking the proxy's exit address. Datacentre ranges and known proxy pools are scored harshly by bot protection, and the block happens after a successful connection.

Fix This is a working proxy and an unwilling target. Re-test against a neutral target such as an IP echo endpoint to confirm the proxy is fine, then decide whether that destination is reachable through that kind of exit at all.

The same proxy passes and fails on alternating runs.

Why it happens Rotating and residential pools reassign the upstream exit per connection, so consecutive checks traverse different paths. Shared proxies also queue under load.

Fix Run the list two or three times and keep the entries that pass consistently. A single pass on a rotating pool describes one exit at one moment, not the pool.

The batch stops before the end of the list.

Why it happens The allowance of 500 proxy checks per visiting IP per UTC day has been used up, and it is shared by everyone behind the same public address.

Fix Split large lists across days, or pre-filter obviously dead entries locally. Copy the failed list so a retry only spends allowance on entries that still need an answer.

When this tool is the right choice

Filtering a freshly delivered proxy list down to the entries that actually connect and authenticate.
Finding out whether a failing proxy has wrong credentials, a dead host, or a destination-side block.
Confirming that a proxy reaches a specific target before you point production traffic at it.
Re-validating a saved list after a provider rotation or a credential change.

When to use something else

Testing a proxy from a particular part of the world. Regional Proxy Exit Check runs the same request from a region you select and takes several samples.
Checking whether your own browser is leaking around a proxy. Browser Leak Check inspects WebRTC candidates and DNS resolvers locally, which a server-side check cannot see.
Measuring a website's availability. Site Check requests a URL directly from multiple regions with no proxy in the path.

Privacy and data handling

The proxy addresses, any usernames and passwords in them, the target URL, and your settings are all sent to this site's server, because the connection has to be made from a machine that can actually reach the proxy. They are used to run the requested check and are not assembled into a user profile, but they pass through the server's request handling and logging in the ordinary way, and the target sees the request arriving from your proxy's exit address. Treat every credential you paste as disclosed to this service: use only proxies you are authorised to test, prefer credentials you can rotate, and remember that the result details display the username and password you supplied, so redact them before sharing a screenshot. The check is limited to 500 proxy checks per visiting IP per UTC day.

Related developer tools

Frequently asked questions

Does an open port mean the proxy works?

No, and that assumption is what the stage field exists to correct. A port can accept TCP and then reject your credentials, fail the handshake, refuse to resolve the destination, or be unable to reach the target. Only a completed request with a status from the target proves the whole path.

How many proxies can I test at once?

Up to 100 unique entries per batch, checked five at a time, with an allowance of 500 checks per visiting IP per UTC day. Exact duplicates are removed before the run, so a list with repeats costs less than its line count.

Does a passing check prove the proxy is anonymous?

No. It proves a connection completed and the target answered. Anonymity depends on which headers the proxy adds or strips, whether it leaks the original client address, what the destination infers from TLS and timing, and what the operator logs — none of which a successful request establishes.

Are my proxy credentials stored?

They are sent to this site's server because the connection is made there, used for that check, and not assembled into a profile. They do pass through ordinary request handling and logging, and the result details show them back to you on screen. Use credentials you can rotate, and redact screenshots.

Which proxy formats are accepted?

The URL form with a scheme — http, https, socks5, or socks5h — with optional credentials, and the colon-separated form host:port:user:pass. Missing ports default to 80 for http, 443 for https, and 1080 for SOCKS5.

Why does the check show a different exit address than the provider lists?

Pools rotate, and providers frequently publish the entry address rather than the exit. The address shown is the one the target connection actually used. If it is consistently outside the range you were sold, raise it with the provider.

May I test any proxy and any target?

Only infrastructure and destinations you are authorised to use. Do not test credentials that are not yours, do not use the checker to get around access controls, and respect both the provider's and the target's rate limits — every check is a real request to someone else's server.