What is a proxy checker? Testing a proxy, step by step

In plain English: a proxy checker sends a test request through your proxy and reports what happened. Did it connect? Which IP address did the website see? How long did the answer take? Did your real address slip out anywhere? Spend any time with proxies and sooner or later you'll meet one that times out, leaks your real IP or just behaves strangely. A checker turns that guesswork into plain facts, so you can fix the actual problem instead of poking at random settings. This guide explains what a checker looks at, how to read its results and how to run checks in a browser or with a few lines of Python.

Quick start in 3 steps

1. Open our proxy checker.
2. Paste in your proxy's address and port, plus the username and password, then run the test.
3. Compare the exit IP it reports with your own address on the my IP tool. The two should be different.

What a checker looks at

A decent checker sends one request through your proxy to a known test address and reports back on several things at once:

• Reachability: does the proxy accept your connection and your login at all?
• Exit IP: the address the destination website sees. It should be the proxy's address, never yours.
• Latency: how long a request takes to get there and back, measured in milliseconds (thousandths of a second). Lower is quicker, and sudden jumps can mean a busy or far-away proxy.
• Protocol support: which ways of talking to the proxy work, such as HTTP, HTTPS and sometimes SOCKS.
• Anonymity level: whether the proxy adds extra information that reveals it's a proxy, or worse, reveals your real address.
• Location: roughly which country and city the exit IP belongs to.

You can check any of our four proxy types this way, whether you have datacenter, residential, mobile or residential premium endpoints.

The three anonymity levels

Proxies are usually sorted into three groups, and a checker tells you which group yours belongs to:

• Transparent: passes your real IP along in extra request information called headers, such as X-Forwarded-For. The website learns both that a proxy is involved and what your real address is. That's rarely what anyone wants.
• Anonymous: hides your real IP, but may still mention that a proxy is involved.
• Elite, also called high-anonymity: hides your IP and gives no sign that a proxy is in use at all. This is the level to aim for in most tasks.

If a checker shows your real IP in any field, stop and fix your settings before doing anything that matters.

The easy way: in your browser

The quickest option needs nothing installed. Open our proxy checker, type the address as host:port, add the username and password, and start the test. Within a couple of seconds you'll see the exit IP, the response time and whether the connection worked. Then look at our my IP tool with the proxy switched off. That shows your normal address, which must not match the exit IP. If they're the same, the proxy isn't really carrying your traffic.

Checking from Python

If you have several proxies to test, a small script is quicker than doing them one by one. The example below sends a request to httpbin.org, a free testing service that replies with the address it sees, times how long that took, and prints both:

import requests
import time

proxy = "http://USER:PASS@HOST:PORT"
proxies = {"http": proxy, "https": proxy}

try:
    start = time.time()
    r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)
    elapsed = round((time.time() - start) * 1000)
    print(f"OK  exit IP: {r.json()['origin']}  latency: {elapsed} ms")
except requests.exceptions.RequestException as e:
    print(f"FAILED: {e}")

The script multiplies the time by 1000 to turn seconds into milliseconds, and the timeout of 15 seconds stops it waiting forever on a dead proxy. To spot a leak, also look at the headers the test service received. If your real IP turns up in X-Forwarded-For or a similar header, the proxy is transparent:

r = requests.get("https://httpbin.org/headers", proxies=proxies, timeout=15)
print(r.json()["headers"])  # scan for any header containing your real IP

Checking a whole list at once

If you look after a list of proxies, loop over it and mark the ones that don't respond. Running several checks side by side (Python calls these threads) keeps the whole job quick:

from concurrent.futures import ThreadPoolExecutor
import requests

proxy_list = [
    "http://USER:PASS@HOST1:PORT",
    "http://USER:PASS@HOST2:PORT",
]

def check(proxy):
    try:
        r = requests.get("https://httpbin.org/ip",
                         proxies={"http": proxy, "https": proxy},
                         timeout=10)
        return proxy, "alive", r.json()["origin"]
    except Exception:
        return proxy, "dead", None

with ThreadPoolExecutor(max_workers=20) as pool:
    for proxy, status, ip in pool.map(check, proxy_list):
        print(status, ip or "-", proxy.split("@")[-1])

Here up to 20 checks run at once, and each one gives up after 10 seconds. The last line splits each proxy at the @ sign and prints only the part after it, so your username and password never end up in a log that someone else might read.

How to read the results

A pass is more than a green tick. Go through these questions:

1. Does the exit IP differ from your own? Compare it with my IP.
2. Is the speed good enough for the job? Collecting web pages copes fine with a few hundred milliseconds; things that happen live, such as video calls, need less.
3. Does the location match what you bought? If you ordered one country and the checker shows another, contact support.
4. Are any headers giving you away? An elite proxy should show none.

If privacy is the reason you're using a proxy, pair this check with our DNS leak test. A proxy can carry your traffic perfectly while your DNS look-ups, the step that turns website names into numbers, still go straight to your own provider and undo all that effort.

Why a check might fail

• 407 Proxy Authentication Required: the username or password is wrong, or the login wasn't sent in the way the proxy expects.
• Connection timeout: a wrong port, a firewall blocking outgoing traffic, or an endpoint that's overloaded.
• Connects fine but shows an unexpected IP: you're probably on a rotating endpoint that changed address between checks. That's normal for rotating residential and mobile pools.
• Your real IP shows up: the proxy is transparent. Switch to a high-anonymity one.

Is this allowed?

Testing proxies you've paid for, or ones you have permission to use, is an everyday part of working with proxies. Don't test or use proxies that belong to someone else without their agreement, such as unknown addresses copied from a public list. You can't tell who runs those or what happens to traffic sent through them, and using them may not be allowed in the first place.

Make checking a habit

Treat the checker as a routine, not a one-off. Use it when new login details arrive, before any big job and whenever something starts acting oddly halfway through. A check that takes seconds can save hours of hunting for a bug in a script that was fine all along, because the real problem was a dead proxy. Still deciding what to buy? The same checker lets you test new proxies as soon as they're ready. You can compare types on the proxies page or look at pricing first.

Beginner questions

Does a slow result mean the proxy is bad?

Not necessarily. A proxy far from you, or far from the test website, takes longer. Run the check a few times. One slow result can be a blip, while results that are slow every time point to a real problem.

Why does my exit IP change every time I check?

You're most likely on a rotating proxy, which gives you a new address on each request or after a set time. That's how it's meant to work. If you need the same address for a while, look for a sticky session option.

Is it safe to type my proxy login into a checker?

Only use checkers you trust, such as the one run by your own provider, because the tool needs your login to make the test. Avoid pasting your details into random sites.

A proxy checker is a small tool that saves a lot of trouble. Use it early, read every field rather than only the pass or fail, and you'll stop blaming your code for problems that started with the proxy.