How to Check If a Proxy Is Working (Free Online Checker)

You grabbed a proxy from a list, dropped it into your scraper or browser, and nothing happened. Was it dead, was it just slow, or was it quietly leaking your real IP the whole time? "Working" is not one thing. A proxy you can actually use has to be alive, reasonably fast, pointed at the country you expect, and private enough for the job. This guide shows you how to check if a proxy is working on all four counts with a tool you already have (curl), plus a faster way if you would rather skip the terminal.

How do I check if a proxy is working?

To check if a proxy is working, send a request through it to an IP-echo service like httpbin.org/ip using curl: curl -x http://IP:PORT https://httpbin.org/ip. If the response shows the proxy's IP instead of yours, it's alive. Add --max-time 10 so dead proxies fail fast instead of hanging. For speed and privacy, also check the timing and the response headers.

What "working" actually means

Before you test anything, know what you're testing for. A proxy passes only if it clears all four of these:

1. Alive. It accepts your connection and returns a real response.
2. Correct exit. It shows its own IP, not yours, and exits in the country you expect.
3. Fast enough. The response time is low enough to be usable for your task.
4. Anonymous enough. It doesn't leak your real IP in the request headers.

A proxy can pass one check and fail another. Plenty of proxies are alive but so slow they're useless, or fast but transparent, which means they hand your real IP to every site you visit. Test all four.

How to check a proxy manually with curl

These examples use the placeholder address 203.0.113.7:8080. Swap in your real IP and port. If you want more detail on running requests through a proxy, see our guide on using proxies with curl.

Step 1: Confirm it's alive

curl -x http://203.0.113.7:8080 --max-time 10 https://httpbin.org/ip

A working proxy returns something like:

{
  "origin": "203.0.113.7"
}

The origin field should show the proxy's IP, not yours. If it shows your own address, the proxy isn't routing your traffic. If the command errors or hits the 10-second timeout, the proxy is dead. Always keep --max-time in there, because a dead proxy will otherwise hang until curl gives up on its own.

Step 2: Check the exit country

Knowing the proxy is alive isn't enough if it exits in the wrong place. Ask a geolocation endpoint for the country code:

curl -x http://203.0.113.7:8080 --max-time 10 https://ipinfo.io/country

This returns a short code like US, DE, or GB. If you bought or picked a proxy for a specific region and it exits somewhere else, treat it as broken for your purpose.

Step 3: Measure the speed

Alive and correct still doesn't mean fast. Use curl's timing output to see how long the connection and full request take:

curl -x http://203.0.113.7:8080 -o /dev/null -s -w "Connect: %{time_connect}s  Total: %{time_total}s\n" https://httpbin.org/ip

On Windows, use -o NUL instead of -o /dev/null. You'll get a line like:

Connect: 0.42s  Total: 0.88s

For light browsing or single requests, a total under about one second is comfortable. Several seconds means the proxy is overloaded and will bottleneck anything you throw at it. Free, shared proxies are usually the slow ones, so this step filters out a lot of them.

Step 4: Test the anonymity

This is the check most people skip, and it's the one that matters for privacy. Look at the headers the destination actually receives:

curl -x http://203.0.113.7:8080 --max-time 10 https://httpbin.org/headers

Scan the output for X-Forwarded-For, Via, and X-Real-Ip. The question is simple: does your real IP appear anywhere in there? If it does, the proxy is leaking you. If instead you see a proxy-identifying header like Via but not your address, the proxy hides you while still announcing that it's a proxy. If the headers look like a plain, direct request, that's the best case.

For a SOCKS5 proxy, every step above is the same, just change the scheme:

curl -x socks5://203.0.113.7:1080 --max-time 10 https://httpbin.org/ip

If you're not sure which type you have, our explainer on what a SOCKS5 proxy is covers the difference.

How to read proxy anonymity grades

The header check in Step 4 maps directly onto three standard grades:

• Transparent. The proxy forwards your real IP (usually in X-Forwarded-For) and identifies itself as a proxy. Websites see exactly who you are. For anything privacy-related, this is no better than no proxy at all.
• Anonymous. The proxy hides your real IP but still reveals that a proxy is being used. Sites know you're behind a proxy, but not which user you are.
• Elite (high-anonymity). The proxy hides your IP and doesn't advertise itself as a proxy. To the destination, the request looks like an ordinary visitor. This is what you want for scraping, sneakers, or account work.

This grade matters more than it sounds. On our own free list as we write this, of the proxies we have graded, roughly one in three comes back transparent, leaking the very IP you used it to hide. Elite is the majority but not by as much as people assume. The grade is not a formality, it is the difference between hiding and only feeling hidden.

Reading raw headers to sort a proxy into one of these buckets takes a minute per proxy and gets tedious fast when you have a list of them.

The faster way: paste it into a free checker

If you don't want to run four commands per proxy, our free proxy checker does all of it in one pass. Paste in the IP and port and it reports:

• the real exit IP,
• the exit country,
• the latency, and
• the anonymity grade (elite, anonymous, or transparent).

It's free, there's no signup, and it works for HTTP and SOCKS proxies. This is the quick way to triage a batch: run each candidate through the checker, keep the elite and fast ones, throw the rest away.

Here is what that looks like in practice. We pasted three proxies straight off our own free list into the checker, and only one still answered, from France, in 30 milliseconds, while the other two had already gone dark in the minute since we grabbed them. That is not the checker being harsh, it is what free proxies actually are, which is the whole reason checking beats trusting.

Where to find proxies that are already checked

If you're testing proxies one by one because your source is unreliable, that's the real problem. Our free proxy list shows a last-checked timestamp and an uptime figure for every entry, so you can pick ones that were confirmed alive minutes ago instead of gambling on a random dump. If you want to pull them into your own tooling, the free proxy API serves the same verified list in a format your scripts can read directly.

Always check right before you use it

Here's the part that trips people up: free proxies die fast. In our data on 537,000 free proxies, lifetimes run in minutes and hours, not days: they're shared by a lot of users, they get overloaded, and providers rotate or pull them within hours. A proxy that passed all four checks this morning can be dead this afternoon. So the timing of your check matters as much as the check itself. Verify a proxy right before you use it, not when you first found it, and rerun the test if a job has been sitting in a queue for a while.

None of this means free proxies are useless. For low-stakes, short-lived tasks they're genuinely fine, and we wrote about when free proxies make sense versus when you want something more stable. The trick is knowing the difference and checking before you trust one.

Test for all four things, check right before use, and you'll stop losing time to proxies that were never going to work. When you want the whole check in one click, paste it into the checker.