Comment vérifier un proxy avant de l'utiliser

A working proxy guarantees nothing yet

The first thing usually checked about a proxy is very simple: does the request go through or not.

If an answer comes back, the proxy counts as working.

For a first pass that is enough. But the test answers only one question:

can a connection be established through this address at all?

It says nothing about which country you come out of, which IP the target site sees, how big the delay is, whether HTTPS is supported, what kind of address is in use and which headers reach the server.

Picture two situations.

In the first the proxy answers in 200 milliseconds and comes out in the country you need.

In the second it also answers, but the request to the target takes several seconds and goes out through an address in a different country.

Formally both proxies work. For a real job these are completely different results.

So the real check starts after the proxy has stopped being merely alive.

Check 1: GEO

The first thing worth knowing is which geographic address you actually get on the way out.

What matters is not the country written in the proxy list but what the outgoing IP resolves to.

The GEO check shows:

• the country;
• the region;
• the city;
• the timezone.

This matters when geography affects how a site or service behaves.

A proxy can be sold as an address in one country while the geolocation database the target uses places it somewhere else. The result is different content, a different region, or the job simply not getting done.

GEO is therefore not a decorative field in a report but a check that the proxy matches the requirement it was bought for.

Check 2: latency

The word speed is used too loosely.

A connection through a proxy has several different legs, and the delay on each can differ.

So it helps to separate:

• host → proxy;
• host → target;
• proxy → target.

That shows not only how big the delay is but where exactly it comes from.

Say the proxy sits next to your server and answers quickly, but the route between the proxy and the target is poor. The final request is slow all the same.

And the other way round: the delay to the proxy can be higher than expected while the leg from the proxy to the target is fine.

A single total hides that difference.

Separate measurements give you more to work with: you can tell which part of the route is worth looking into.

Check 3: URL

Checking whether an address opens through the proxy answers a practical question:

does this proxy work where it is actually needed?

A proxy can accept connections and pass a basic test without giving access to one particular URL.

So what needs checking is not abstract availability but the direction you need.

You get the HTTP response code and see that the target really is reachable through this proxy.

That matters most when a proxy is not used on its own but as part of a specific job.

Check 4: outgoing IP

The proxy settings and the actual outgoing address are not the same thing.

The target sees the IP the request finally came from. That is the one to check.

The test confirms that the request really leaves through the intended proxy and does not end up on a different address.

It is also useful when the proxy list holds stale or wrong data.

Instead of assuming which address should be on the outside, you get the actual one.

Check 5: HTTPS

An HTTP proxy can be perfectly functional and still be wrong for a job that needs HTTPS.

A separate check shows whether the proxy can tunnel an HTTPS connection.

That is the line between the proxy answers and the proxy is fit for the work.

If the job involves sites, APIs or anything else served over HTTPS, this belongs in the first pass rather than after the problem shows up.

Check 6: MITM

A successful HTTPS request does not mean the traffic passed through unchanged.

In a MITM interception the middleman sits between client and server and sets up separate connections on each side. For the client to trust such a connection, the device has to hold a matching chain of trust.

Some corporate networks do this deliberately: the organisation installs its own trusted certificate and gains the ability to inspect traffic. That can be a legitimate part of the infrastructure.

So the question is not whether MITM is bad in itself.

The question is different:

is the traffic being altered, and do you know about it?

For an ordinary checker this is not an obvious test. A successful response says nothing about what happened between the two sides.

Check 7: proxy type

The same connection method can use different kinds of IP address.

Proxy Checker works out whether the address looks like:

• a datacenter address;
• a residential one;
• a mobile one.

This is separate from geography and from anonymity.

Two proxies in the same country answering equally fast can still have different origins, which means the target may treat them differently.

So the type is worth checking on its own rather than inferring it from the country of the IP.

Check 8: anonymity

Proxies do not all hide the original IP equally well.

What matters in an anonymity check is not only the final level but the traces the proxy leaves in the HTTP request.

For instance, X-Forwarded-For is used to pass information about the original client IP through a proxy or intermediate infrastructure. There is also the standardised Forwarded, which can carry information about the client, the protocol and the proxy.

So the word anonymous on its own explains very little.

It is far more useful to see the specific suspicious headers and understand what exactly the proxy reports about itself and about the client.

What to check on a proxy in the end

If the job is simply to see whether an address answers, a basic request will do.

If the proxy is going into a working setup, eight characteristics are worth checking at a minimum:

1. GEO — where the outgoing IP sits.
2. Latence — where exactly the delay comes from.
3. URL — whether the resource you need is reachable.
4. IP externe — which address the target actually sees.
5. HTTPS — whether an HTTPS tunnel is supported.
6. MITM — whether the traffic is altered.
7. Type — datacenter, residential or mobile.
8. Anonymat — which level, and which headers the proxy gives away.

A set like that answers not whether the proxy is alive but whether this proxy fits my job.

How to check a large list

With one proxy you can open a few services and check it by hand.

With dozens or hundreds of addresses the approach changes.

Instead of separate checks it is easier to run the whole list through one set of tests and get the same data for every address.

Proxy Checker handles up to 1000 proxies in a single run without signing up. Every result goes into a report you can download as TXT or JSON.

That lets you filter the list not by a single works criterion but by the parameters that actually matter for what comes next.

FAQ