How to Test a Proxy: IP, Latency, Anonymity and Leaks

Getting a response from a proxy is not enough. Before you trust it with a scraper, a rank tracker or client accounts, you need to know which IP it shows, from which country, how fast it is, and whether your real address slips out through another route. These checks take a few minutes and can save you days of skewed results.

Here is the method, step by step, using Airproxy's two free tools (no account needed) and a few simple commands.

Check the exit IP and country

Start with the address websites actually see. Set up the proxy in your browser or in the relevant profile, then open What is my IP. The tool shows the public IP, country, city, provider, ASN and time zone. Check three things:

• The IP shown is not yours. If you see the address of your home router or your server, your traffic is not going through the proxy: go back over the setup with our guide on how to set up a proxy.
• The country is right. It should match the location you bought and the market you are targeting.
• The provider makes sense. For an ISP proxy, you would expect a consumer internet provider rather than a hosting company.

Geolocation databases differ from one service to another, especially at city level: see our guide on how to choose a proxy location.

Test availability, latency and speed

The proxy checker tests an HTTP, HTTPS or SOCKS5 proxy without touching your own setup. Paste the credentials in ip:port:username:password format, pick the protocol and run the test. You get:

• availability: does the proxy respond and accept your credentials?
• ping: the time it takes to open a connection to the proxy;
• latency: how long a real HTTPS request takes to go through the proxy;
• the exit IP, location, provider and anonymity level.

These measurements are taken from the tool's server. They tell you whether the proxy is healthy, but the latency you actually get also depends on the distance between your machine and the proxy, then between the proxy and your target. So run the test again from your own infrastructure, at different times of day: steady latency matters more than one good reading.

Measure throughput

Download a file of known size through the proxy and let curl do the math:

curl -x "http://USERNAME:PASSWORD@HOST:PORT" -s -o /dev/null \
  -w "connect: %{time_connect}s\nttfb: %{time_starttransfer}s\nspeed: %{speed_download} B/s\n" \
  https://example.com/test-file.bin

Here, connect measures the connection to the proxy, ttfb the arrival of the first byte sent by the website, and speed the average throughput in bytes per second. Pick a file hosted close to your real target and repeat the measurement, since throughput varies with network load. To build these checks into your scripts, see our guide on how to use a proxy in Python, Node.js and curl.

Understand anonymity levels

An HTTP proxy can add headers to your requests. Two of them give it away: Via, which signals that an intermediary relayed the request, and X-Forwarded-For, which can pass along the client's original address. Depending on what the proxy adds, there are three levels.

The proxy checker works out this level for you: it calls a page that echoes back the headers it received and looks at what the proxy added. With SOCKS5, the proxy relays the connection without rewriting your HTTP headers, so what the website receives depends on your software. Keep in mind that an elite proxy does not hide the rest of your fingerprint: cookies, language, time zone and WebRTC still need checking.

Detect DNS and WebRTC leaks

A leak is any information that goes out by a route other than the proxy. The two most common ones involve DNS and WebRTC.

DNS leaks

Before it can reach a website, your software has to translate the site's name into an IP address. If that lookup happens on your machine, your usual resolver, often the one run by your internet provider or your hosting company, sees every domain you visit. The website does not see your IP, but this information leaves without going through the proxy, and the resolver's location may contradict the IP's.

With an HTTP(S) proxy, the site's name is usually sent to the proxy, which resolves it itself. With SOCKS5, it all depends on the client: you have to ask for remote resolution. With curl and many libraries, that is the job of the socks5h:// scheme (the “h” stands for hostname); with socks5://, the name is resolved locally.

curl -x "socks5h://USERNAME:PASSWORD@HOST:PORT" https://example.com

In Firefox, the option that hands DNS over to the SOCKS v5 proxy is in the connection settings (the network.proxy.socks_remote_dns preference). To check, open a DNS leak test page through the proxy: it lists the resolvers that queried it. If your internet provider's resolver shows up, lookups are still happening locally. Our HTTP vs SOCKS5 proxy guide covers the differences between the two protocols in detail.

WebRTC leaks

WebRTC lets browsers set up direct audio and video calls. To find the best route, it queries outside servers over UDP, traffic that most proxies do not relay. A web page can therefore discover your real public IP even when all your browsing goes through the proxy. Recent browsers hide local network addresses, but not necessarily your public IP.

Open a WebRTC test page through the proxy: if your real IP appears, you have a leak. To limit it:

• in Firefox, disable WebRTC with the media.peerconnection.enabled preference in about:config;
• in Chromium-based browsers, setting the WebRtcIPHandling policy to disable_non_proxied_udp stops WebRTC from using UDP outside the proxy;
• in a multi-profile browser, check the WebRTC setting of each profile and run the test again after every update.

Check the IP's reputation

An IP can work perfectly and still have a bad name. If an address has been used for spam or abuse, it may sit on blocklists, and some websites will throw CAPTCHAs at it or turn it away.

• Look up public blocklists. Free lookup services tell you whether an address appears on DNSBL lists. These lists are mostly about email: a listed IP is not necessarily blocked by your target, and an unlisted one is not necessarily welcome.
• Check the ASN. The What is my IP tool shows the provider and the ASN: a hosting range gets filtered more often than a consumer provider's range.
• Run a real-world test. A few manual requests to your target tell you more than any list: a normal page, a CAPTCHA every time, a 403 or 429 error?

With a dedicated IP, its reputation depends only on how you use it: you never inherit other users' behavior. That is one of the arguments in our dedicated vs shared proxy comparison.

Checklist before going live

1. The exit IP is not yours and is located in the expected country.
2. The provider shown matches the type of proxy you bought.
3. The proxy responds over the protocol you will use (HTTP, HTTPS or SOCKS5), with your credentials.
4. The anonymity level is “elite”.
5. Latency stays steady across several measurements taken from your infrastructure, and throughput is enough for the planned volume.
6. No DNS leak (remote resolution over SOCKS5 with socks5h://) and no WebRTC leak in your browser profiles.
7. The time zone and language of your profiles match the IP's country.
8. The IP does not trigger systematic blocking on your target.
9. Your use complies with the target websites' terms, their robots.txt and the GDPR.

Airproxy's dedicated ISP proxies are delivered in host:port:username:password format, with the same access over HTTP(S) and SOCKS5, so you can run through this checklist as soon as they arrive. Available locations are listed on the offers page.