Checking Proxies Before Use: A Checklist

Checking takes ten minutes and saves considerably more. A seller describes an address the way that suits them; verification is your job.

Is it alive

The obvious first step: the address responds and requests pass through it.

Worth looking at straight away:

• Does an ordinary request get through. If not, there is nothing else to check.
• Is it stable. Ten requests in a row rather than one: an address that answers intermittently is unusable in production.
• Do both protocols work, if you need HTTP and SOCKS.
• Are the credentials right. A username and password or IP-based authorisation - sellers differ.

Country and geolocation

The advertised country and the actual one diverge more often than you would like.

Check against several sources: geolocation databases differ between services, and the platform may use the one that shows something other than what you expected.

What matters:

• Country and city, especially when the task depends on the region.
• Consistency with everything else. A French address with a system time zone and language from another country is a mismatch the platform can see. The environment must match the address - see profiles and isolation.
• Address type. Check whether it is detected as a server address: a seller may have called something residential that is not - see residential versus datacentre.

Leaks

The trickiest category: the proxy works correctly and your real address is visible anyway.

A WebRTC leak. The browser reports your real address to the site through a separate mechanism, bypassing the proxy. Traffic honestly goes through the proxy; the leak takes another route.

A DNS leak. Domain name lookups go around the proxy, and the provider serving them reveals your real location.

A time zone mismatch. An address in one country, a system clock in another. Formally not a leak, and just as visible a signal.

Language and keyboard layout. The same.

All of this is checked with pages that display every address and parameter a site can see. Check in the browser you will actually work in, not the system one: settings differ.

Speed

Residential and mobile addresses are slower than datacentre ones, which is normal. What matters is different:

• Is the latency acceptable for your task. Tolerable for accounts, potentially critical for bulk scraping.
• Is the speed stable. An address that alternates between fast and slow breaks automation through timeouts.
• Is there a traffic cap. Residential is usually billed by traffic, which is worth understanding beforehand - see rotation.

Blocklists

The step people skip most often.

The address may have been used before you, and its history stays with it. What to check:

• Whether it appears in public lists of abusers and spam sources.
• Whether it is flagged as a proxy or VPN. Some services detect that, and the platform may use the same data.
• Whether somebody else is using it right now. With cheap sellers one address is often sold to several customers.

The practical conclusion: an address with a bad history is worse than no proxy. You are not getting a neutral address but one that arrives already suspected.

The checklist

• The address responds consistently.
• Country and city match, verified across several sources.
• The address type matches what was promised.
• No WebRTC or DNS leaks.
• Time zone and language match the address.
• Speed is acceptable and stable.
• The address is not blocklisted.
• Nobody else is using it in parallel.

Repeat the check periodically: an address that was clean a month ago may now be listed. That applies especially to addresses you share with a seller’s other customers.

The overview is in the proxy guide.