How to Test a Proxy and Avoid Common Setup Mistakes

A new proxy deserves a few checks before any account or project comes to depend on it. They take little time, and most of the trouble people run into turns out to be a matter of configuration on their own side, with the proxy itself at fault far less often. Both are covered below.

1. Check the IP, ISP and location

Open an IP lookup site through the proxy, either inside the browser profile that will be using it or from a terminal:

curl -s -x http://USER:PASS@HOST:PORT https://ipinfo.io/json

• ISP / org: a residential proxy has to show a consumer internet provider. A hosting or cloud company in that field means it is a datacenter proxy.
• Location: should correspond to what you purchased.
• IP: with a static proxy, repeat the check the following day and expect the very same address.

2. Check the fraud score

Look the IP up on a reputation checker such as IPQS or Scamalytics. What you are after is a low score and no "proxy" or "VPN" flag. How to read the result is explained in IP fraud scores explained.

3. Check for leaks

A proxy conceals only the traffic that actually passes through it. The following commonly find a way around:

• WebRTC. Browsers are able to expose your real IP through WebRTC even with a proxy configured. Run a WebRTC leak test inside the profile, where the proxy's IP should be the only one to appear.
• DNS. When lookups are performed by your own machine, your ISP's DNS servers show up alongside a US proxy IP. A DNS leak test should list servers consistent with the proxy's location, and with SOCKS5 the "proxy DNS" option or its equivalent needs to be enabled.
• IPv6. On a connection with IPv6 and a proxy that is IPv4 only, part of the traffic may leave over your own IPv6 address. Disabling IPv6 in the profile or on the machine prevents it.

4. Common anti-detect browser mistakes

These account for most cases of "the proxy got my account flagged":

• A timezone that does not match the IP. A Virginia IP paired with a European clock is a glaring mismatch. Have the timezone set from the proxy.
• A language or locale that does not match. By the same logic, a US IP ought to come with US English unless there is a reason for it not to.
• Geolocation left on the real location. Set it from the IP or block it altogether.
• WebRTC left on its default. As described above.
• The wrong proxy type. Entering a SOCKS5 proxy as HTTP, or the other way round, either fails outright or sends part of the traffic outside the proxy. This matters most for game clients that depend on UDP, as covered in SOCKS5 UDP proxies for game automation.
• One proxy across several profiles. This links the accounts together. Stick to one IP per profile.
• A first login made without the proxy. By then the account has already seen your real IP.

Once the settings are corrected, open a fingerprint or IP checker inside the profile and confirm that IP, timezone, language and DNS all point to the same place.

5. Speed, with a caveat

Speed tests run from your own device mostly end up measuring your own connection. Using a US proxy from Europe sends every request across the Atlantic twice, and no download test can outpace your home line, so a slow result under those conditions says very little about the proxy.

What can be judged fairly is whether pages load without stalling and whether the connection holds. For meaningful figures, test from a server located near the proxy.

6. Check stability over a day

Leave the proxy in use for a full day. A static proxy should hold the same IP throughout without dropping connections. Occasional failures are par for the course on rotating networks and should be rare on static ones.

What to expect from ours

A Leastslow proxy shows a US consumer ISP in Ashburn, Virginia, a fraud score of zero, and the same IP day after day. HTTP and SOCKS5 share a single port, and UDP is supported through SOCKS5. The price list starts at a single IP, should you wish to run these checks yourself.