How to Test Proxies: Check Speed, IP Quality, Leaks and Errors Before You Use Them

How to Test Proxies: Check Speed, IP Quality, Leaks and Errors Before You Use Them

If your proxy connects, that doesn’t necessarily mean that the proxy works. It can return the right IP and still be too slow for your scraper. It can have a low IP reputation or be on a blacklist that gets you blocked on the first request. It can leak your real IP through DNS or WebRTC, or fail with a 502 the moment you scale up. Knowing how to test proxies before you put them into production saves you bans, failed jobs, and wasted bandwidth.

This guide gives you a repeatable proxy quality test you can run on a single IP or an entire pool. It covers five areas: connectivity, speed, IP reputation, anonymity and leaks, and error behavior. Each step includes the commands to run and what a passing result looks like.

Why You Should Test Proxies Before Using Them

Proxy quality varies by a lot, even between IPs from the same provider. A few factors explain most of the difference:

• Proxy type. Datacenter proxies are fast and cheap but easy for websites to identify as hosting traffic. Residential, ISP (static residential), and mobile proxies carry more trust but add latency, because traffic is routed through real consumer connections.

• Source and sharing. Free and heavily shared proxies are often already flagged by the sites you want to reach. Dedicated IPs have a cleaner history, but only if the previous owner used them well.

• Configuration. Many "bad proxies" are in fact fine proxies with a wrong protocol, auth format, or browser setting.

Above all, a proxy is only good for a specific job. An IP that loads a product page perfectly could be instantly challenged on a login page. This is why we ended the tests below with a check against your real target. If you are managing accounts or scraping protected sites, read our guides on how to run multiple accounts safely and how to avoid Cloudflare blocks when using proxies for the detection side of the picture.

What a Complete Proxy Quality Test Covers

A useful proxy quality test checks five things, in this order:

The order matters. There is no point checking the fraud score of a proxy that fails authentication, or benchmarking a proxy that leaks your real IP.

Step 1: Check If the Proxy Is Working

Before anything else, confirm three details from your provider: the protocol (HTTP, HTTPS, or SOCKS5), the host and port, and the authentication method. Most providers support either username and password, or IP whitelisting, where the proxy only accepts connections from approved IP addresses.

The fastest way to check if a proxy is working is a single curl request to an IP echo service:

# HTTP proxy with username/password
curl -x http://USER:PASS@HOST:PORT https://api.ipify.org

# SOCKS5 proxy, with DNS resolved by the proxy (note the "h")
curl -x socks5h://USER:PASS@HOST:PORT https://api.ipify.org

The proxy works if the response is a single IP address, and it should be the proxy's exit IP, not your own. Run the same command without -x to see your real IP for comparison.

If the request fails, the error tells you where to look:

• No response or "connection refused": wrong host or port, the wrong protocol, or a firewall blocking the port.

• 407 Proxy Authentication Required: the proxy rejected your credentials, or your IP is not whitelisted.

• The request succeeds but shows your real IP: the proxy is not being applied, which is common when an environment variable or app setting overrides your config.

Passwords containing special characters such as @ or : must be URL-encoded inside the proxy URL, or curl will misread them. The curl documentation covers the full proxy syntax, including the separate -U / --proxy-user option for passing credentials.

To check in a browser, configure the proxy and open any "what is my IP" page. If you are setting up proxies in an antidetect browser, our SOCKS5 antidetect browser setup guide walks through the configuration step by step.

Step 2: Test Proxy Speed and Latency

"Speed" is really several measurements. Each one points to a different bottleneck:

• Connect time: how long the TCP connection to the proxy takes. This is mostly distance and network quality between you and the proxy server.

• TLS handshake: for HTTPS targets, the encrypted handshake with the target site, tunneled through the proxy.

• Time to first byte (TTFB): when the first byte of the response arrives. This includes the proxy's routing and the target server's processing time.

• Total time and throughput: how long the full response takes, and how much data per second the proxy can move.

curl can break these down with its -w (write-out) option:

curl -x http://USER:PASS@HOST:PORT -o /dev/null -s -w \
"dns:        %{time_namelookup}s
connect:    %{time_connect}s
tls:        %{time_appconnect}s
first byte: %{time_starttransfer}s
total:      %{time_total}s
proxy code: %{http_connect}
http code:  %{http_code}
" https://example.com

All times are cumulative from the start of the request. A large jump between connect and first byte points to slow routing or a slow target. A high connect value points to a distant or congested proxy server.

To get numbers you can trust:

1. Run each test 10–20 times and look at the median and the worst results, not one lucky run. Consistency often matters more than raw speed.

2. Test against your real targets, not only speed-test endpoints. A proxy can be fast to a CDN and slow to the site you actually need.

3. Account for geography. A US residential IP reaching a European site will always add latency. Pick proxy locations close to your target servers when you can.

4. Compare like with like. Residential and mobile proxies are typically slower than datacenter proxies because traffic passes through consumer connections. Benchmark each type against its own baseline.

If you would rather not script this, CoreProxy's Proxy Benchmark and Speed Test tools give you a quick read. When the numbers come back worse than expected, our deep dive on why your proxy is slow and how to fix proxy latency explains how to isolate the cause.

Step 3: Check IP Quality and Reputation

A fast proxy is useless if the target site distrusts its IP. IP quality comes down to four checks.

Geolocation accuracy. Look up the exit IP in more than one geolocation database. Databases often disagree, and websites may use a different one than you do. If you bought German IPs and half your lookups say the Netherlands, expect geo-restricted content to behave inconsistently. You can check quickly with CoreProxy's IP Location tool.

ASN and ISP type. Every IP belongs to an Autonomous System Number (ASN) operated by an organization. A residential proxy should resolve to a consumer ISP, not to a cloud or hosting provider. If your "residential" IP belongs to a hosting company, many websites will treat it as datacenter traffic regardless of what the plan is called.

Fraud score and blacklists. IP risk services assign scores based on observed abuse, proxy or VPN detection, and recent activity. Abuse-report databases and DNS-based blocklists (DNSBLs) record IPs linked to spam, attacks, or bots. Keep in mind that many well-known blocklists are built for email filtering. A listing there matters a lot for sending mail and less for browsing, but it is still a signal of the IP's history.

Usage history. Shared and recycled IPs inherit the reputation of everyone who used them before you. An IP that was hammered by another scraper last week may be rate-limited on your target today.

The most reliable reputation test is the real one: send a handful of normal requests to your target and watch for CAPTCHAs, 403 responses, or block pages. For a full walkthrough of fraud scores, blacklist lookups, and what scores are acceptable, see Proxy IP Reputation: How to Check Fraud Score and Blacklists Before You Use an IP.

Step 4: Test for Leaks and Anonymity

A proxy can hide your IP in one place and reveal it in another, so test at both the proxy level and the browser level.

Anonymity level (header leaks)

Proxies are commonly grouped into three anonymity levels:

• Transparent: forwards your real IP to the target, usually in the X-Forwarded-For header.

• Anonymous: hides your IP but announces that a proxy is in use, for example with a Via header.

• Elite (high anonymity): adds no identifying headers, so the request looks like it came directly from the proxy IP.

To check, request a header echo endpoint over plain HTTP:

curl -x http://USER:PASS@HOST:PORT http://httpbin.org/headers

Look for X-Forwarded-For, Via, Forwarded, or X-Real-Ip headers in the response. Plain HTTP matters here. With HTTPS, the proxy only opens an encrypted tunnel and cannot add headers inside it, so an HTTPS test will hide a header problem rather than reveal it.

DNS leaks

Even when traffic goes through the proxy, your device may still resolve domain names using your local DNS server. That exposes the sites you visit, and your rough location, to your ISP and to anyone watching DNS. With SOCKS5, make sure DNS is resolved by the proxy: use socks5h:// in curl and similar clients, and enable remote DNS ("Proxy DNS when using SOCKS v5") in Firefox. Then run a DNS leak test in the browser. The resolvers it shows should belong to the proxy's network, not your ISP. CoreProxy's DNS Lookup tool is useful for inspecting individual records.

WebRTC leaks

WebRTC lets browsers make direct peer-to-peer connections, and it uses STUN servers to discover public IP addresses. Because this traffic often runs over UDP, it can bypass an HTTP or SOCKS proxy configured in the browser and expose your real public IP to any website that asks for it. Test with a WebRTC leak checker while the proxy is active. If your real IP appears, disable non-proxied UDP in the browser, use an extension that limits WebRTC, or let your antidetect browser replace the WebRTC IP with the proxy's.

IPv6 leaks

If your proxy only carries IPv4 traffic but your device has IPv6 connectivity, any app or system service that bypasses the proxy can reach sites over IPv6 with your real address. This is most common with system-wide proxy settings. Check with an IPv6 checker while connected: if it shows an IPv6 address you don't recognize as the proxy's, you have a leak.

Browser signals

Finally, compare your browser's timezone, language, and locale with the proxy's location. A browser set to Berlin time and German language behind a US IP is a classic mismatch that anti-bot systems check for.

Step 5: Identify and Troubleshoot Proxy Errors

When a request fails, the first job is to work out who is complaining: the proxy, the target site, or your own setup. Proxy errors usually appear in the CONNECT response (%{http_connect} in curl). Target errors appear in the final HTTP status code.

The 407 and gateway codes (502, 504) are defined in the HTTP standard, RFC 9110, which is worth reading if you build your own proxy tooling. A 407 response includes a Proxy-Authenticate header describing the expected authentication method, and your client must answer with a Proxy-Authorization header.

For a deeper troubleshooting guide with fixes for each code, see Proxy Error Codes Explained: How to Fix 407, 502, 504 and ERR_TUNNEL_CONNECTION_FAILED.

Step 6: Test Stability and Success Rate at Scale

One good request proves very little. Before you rely on a proxy pool, measure how it behaves over hundreds of requests. This short Python script checks a list of proxies in parallel and reports the success rate, latency, and exit IP for each:

import time
import requests
from concurrent.futures import ThreadPoolExecutor

# One proxy per line, e.g. http://user:pass@host:port
# For SOCKS5 use socks5h://... and install requests[socks]
with open("proxies.txt") as f:
    PROXIES = [line.strip() for line in f if line.strip()]

TARGET = "https://api.ipify.org?format=json"

def check(proxy):
    start = time.perf_counter()
    try:
        r = requests.get(TARGET, proxies={"http": proxy, "https": proxy}, timeout=15)
        elapsed = round(time.perf_counter() - start, 2)
        return proxy, r.status_code, elapsed, r.json().get("ip")
    except requests.RequestException as e:
        return proxy, "error", None, type(e).__name__

with ThreadPoolExecutor(max_workers=20) as pool:
    results = list(pool.map(check, PROXIES))

ok = [r for r in results if r[1] == 200]
print(f"Success rate: {len(ok)}/{len(results)}")

for r in results:
    print(r)

Repeat it against your real target URL and at different times of day. Also check:

• Rotation. On a rotating endpoint, send 10–20 requests and count the unique exit IPs. You should see rotation that matches your settings.

• Sticky sessions. If you pay for sessions that hold the same IP for a set time, confirm the IP actually stays the same for that full period.

• Drift. Track success rate and median latency over several days. Gradual decline usually means the IPs are being flagged by your targets.

Scale testing also shows you where bandwidth goes. Retries, failed requests, and oversized pages all add cost. Our guide on how to cut proxy costs covers how to reduce that waste.

Proxy Checker Tools: Online vs. Self-Hosted

You can run every test above by hand, but a proxy checker speeds things up, especially for large lists. There are three main options:

• Online proxy checkers are the quickest: paste a list and get status, latency, and exit IP back. Most run tests from their own servers, so the latency they report reflects their location, not yours. You also have to share your proxy credentials with a third party, so only use checkers you trust. CoreProxy's Proxy Checker tests HTTP and SOCKS5 proxies in bulk, reports connectivity, latency, exit IP, and success rate, and lets you copy working IPs or clear failed ones. As with any checker, test requests count toward your bandwidth.

• Desktop tools run from your own machine, which gives more realistic latency, but they vary widely in quality and transparency.

• Your own scripts, like the one in Step 6, give you full control. You can test against your real targets, log results over time, and plug checks into your pipeline.

For anything business-critical, combine a quick online check with your own tests against real targets.

Pre-Use Proxy Testing Checklist

Run through this before you put any proxy into production:

• 

  Connectivity: request succeeds with the correct protocol and auth; returned IP is the proxy's, not yours

• 

  Speed: median timings over 10+ runs fit your budget; no extreme outliers

• 

  Location: exit IP geolocates to the expected country or city in several databases

• 

  IP type: ASN matches the proxy type you paid for (residential ISP vs. hosting)

• 

  Reputation: low fraud score; no major blacklist listings relevant to your use case

• 

  Headers: no X-Forwarded-For, Via, or similar headers on a plain HTTP test

• 

  DNS: resolvers belong to the proxy network, not your ISP

• 

  WebRTC and IPv6: no leak of your real IP

• 

  Browser signals: timezone and language match the proxy location

• 

  Errors: no recurring 407, 502, or 504 errors

• 

  Stability: high success rate over hundreds of requests; rotation and sticky sessions behave as promised

• 

  Target test: a few real requests to your target site return normal pages, without CAPTCHAs or blocks

FAQ

How do I check if my proxy is working? Send a request through the proxy to an IP echo service such as api.ipify.org. If it returns the proxy's IP rather than yours, the proxy is working. If it fails, the error tells you whether the problem is connectivity, authentication, or configuration.

What is a good proxy response time? It depends on the proxy type and the distance to your target. Datacenter proxies are generally the fastest, while residential and mobile proxies add latency because traffic passes through consumer networks. Rather than chasing a universal number, set a baseline for each proxy type against your real target and watch for consistency.

How often should I test my proxies? Test when you buy them, before every major job, and continuously for anything running at scale. IP reputation and performance change over time, so a proxy that passed last month may fail today.

Are free online proxy checkers safe? They are fine for quick checks, but you are sharing your proxy credentials with a third party, so only use checkers you trust.

Why does my proxy work in the browser but not in my script? Common causes are a protocol mismatch (an HTTP scheme used for a SOCKS5 proxy), special characters in the password that need URL-encoding, missing SOCKS support in your HTTP library, or environment variables overriding your proxy settings.

Conclusion

Learning how to test proxies comes down to five checks, run in order: confirm the proxy works, measure its speed, verify the IP's quality, rule out leaks, and watch how it behaves under real load. Testing once at purchase is not enough. Reputation and performance shift over time, so build these checks into your routine.

When a test flags a problem, go deeper with our guides on proxy error codes, IP reputation and fraud scores, and fixing slow proxies.