How to test proxies: 8 methods to check speed and location

Key takeaways

• Testing a proxy means checking that it is alive, how fast it responds, what exit IP and location it returns, which headers it reveals, and whether it routes every request without leaks.
• Start with a browser-based proxy checker for a quick yes or no, then move to curl and Python when you need repeatable, scriptable results across a whole proxy list.
• The fastest reliability signal is the response code. A 200 means the proxy works, a 407 means your username or password is wrong, and a timeout usually means the wrong protocol or an IP that is not allowlisted.
• Match the proxy type to the test target: rotating residential for high-volume jobs, static residential or ISP for stable sessions, and datacenter for high-throughput public content.

A proxy that connects is not the same as a proxy that works for your task. It can be online but slow, return the wrong country, pass your real IP in a header, or fail on the one site you care about. The eight methods below run from a 10 second browser check to a Python script that tests a full list, so you can verify any proxy before it reaches production.

What does it mean to test a proxy?

Testing a proxy means confirming it does the job you bought it for. That breaks down into a handful of measurable checks across the main proxy types:

• Connectivity (is it alive?). The proxy accepts your connection and returns a response. This is the pass or fail gate before anything else matters.
• Speed and latency. How long the proxy takes to connect and return data. Slow proxies quietly drag down scraping throughput and page-load tests.
• Exit IP and location. The IP address and country the target site actually sees. For any geo-specific task, the exit location has to match the market you are testing.
• Header transparency. Which request headers reach the target. Some proxies forward your real IP in headers like X-Forwarded-For; others pass nothing extra.
• Leak safety. Whether every request, including DNS lookups, routes through the proxy rather than slipping out over your own connection.
• Success rate on real targets. A proxy can pass a generic check and still fail on the specific site you care about, so the final test is always your real target URL.

A quick online checker covers the first three in seconds. The rest need a request you control, which is where curl and Python come in.

What you need before you start

You need four things to test a proxy properly:

1. The proxy details. Host, port, and either a username and password or an allowlisted IP. Proxy-Cheap delivers these in the dashboard under "Setup Credentials," in standard host:port plus username:password form.
2. The endpoint type. Rotating products use a shared gateway. The Proxy-Cheap rotating residential gateways are proxy-us.proxy-cheap.com:5959 for the US pool and proxy-eu.proxy-cheap.com:5959 for the EU pool, and each request returns a fresh IP. Static products (static residential, ISP, datacenter) give you a unique IP and port per proxy, copied straight from the dashboard.
3. A test endpoint. A URL that echoes back what the server sees. https://httpbin.org/ip returns the exit IP, https://httpbin.org/headers returns the headers, and https://ipinfo.io/json adds location and network owner.
4. A client. A browser or online checker for a quick look, plus curl or Python (what curl is, in short, is a command-line tool for sending requests). Both come preinstalled on most systems.

One rule throughout: keep credentials in their own field, not baked into a shared URL you might paste somewhere public.

Method 1: Check if the proxy is alive with curl

The fastest scriptable test is one curl command. The -x flag sets the proxy, --proxy-user passes credentials in their own field, and https://httpbin.org/ip echoes the exit IP back to you.

A proxy test sends one request through the Proxy-Cheap gateway to a check endpoint like httpbin.org/ip, then reads the exit IP, status code, and response time from what comes back.

A working proxy returns the IP it routed through:

If that IP differs from your own, the proxy is alive and routing traffic. To read the status code on its own, send the body to nowhere and print only the code:

A 200 confirms a clean round trip. If you do not get a 200, the most common cause is a credential problem, which Method 7 covers in detail. For a deeper walkthrough of the syntax, see how to use curl with a proxy.

Method 2: Confirm your exit IP and its location

A proxy that connects can still return the wrong country. For any geo-specific job, ad verification, localized pricing, or rank tracking, you have to confirm the exit location matches what you ordered.

ipinfo.io/json returns the IP plus its city, region, country, and network owner in one call:

Check three fields. The country should match your target market. The org line tells you the network type: a residential or mobile carrier name points to a rotating residential or mobile IP, while a hosting company name points to a datacenter IP. The timezone is a quick sanity check that the location is internally consistent.

For a no-setup version of this check, paste the proxy into a browser-based checker, covered next.

Method 3: Use a browser-based proxy checker

When you do not want to touch a terminal, an online proxy checker does the same job in the browser. You paste a list of proxies, the tool routes a request through each one, and it reports which are alive, how fast they responded, the country, and the protocol (HTTP or SOCKS). It is the fastest option for a long list, for non-developers, or for a second opinion that does not depend on your local setup.

Most checkers accept the common formats: ip:port, user:pass@ip:port, and ip:port:user:pass. The tradeoff is depth: a browser checker reports status, speed, and location, but it will not test your real target site or show you the full request headers. Use it as a first filter, then verify the survivors with curl or Python. You can also test a proxy manually by setting it in your browser or OS network settings, then opening ipinfo.io to confirm the IP and country change as expected.

Method 4: Measure proxy speed and latency

A proxy can be alive and still too slow to be useful. curl exposes precise timing through its -w write-out variables, so you can measure connect time and total time with no extra tooling:

Two numbers matter. time_connect is how long it took to reach the proxy and open the tunnel, which reflects network distance and proxy load. time_total is the full round trip. Run the same command three to five times and watch the spread. A stable proxy returns consistent numbers; a flaky one swings widely. For a fair comparison, test every proxy against the same endpoint from the same machine.

Residential IPs naturally run a little slower than datacenter proxies because traffic routes through a real consumer connection. That is the expected tradeoff: datacenter IPs deliver high throughput for public, unprotected targets, while residential IPs return the most accurate results on sites that vary their content by visitor.

Method 5: See which headers your proxy reveals

When you route a request through a proxy, the target server sees a set of request headers. Some proxies add headers that carry your original IP; others pass nothing extra. Checking this tells you how much the proxy reveals about the connection behind it.

httpbin.org/headers echoes back exactly what the server receives:

Look for two headers in the response, X-Forwarded-For and Via. They sort the proxy into one of three behaviors:

• Transparent. The target sees X-Forwarded-For containing your real IP. The proxy forwards traffic but does not protect the origin. Fine for caching, not for privacy-sensitive testing.
• Header-adding. The target sees a Via or proxy header that signals a proxy is in use, but your real IP is not in the request.
• No-forwarding. The target sees a normal browser header set with no X-Forwarded-For and no Via. Your origin IP is not in the request at all.

On a clean, direct connection the target sees only standard headers like Host, User-Agent, and Accept, with no X-Forwarded-For. A quality residential or mobile IP behaves the same way through the proxy, which is what you want for privacy-sensitive and location-accurate work.

Method 6: Check for IP and DNS leaks

A proxy is only doing its job if every part of the request goes through it. A leak happens when some traffic, often DNS lookups or browser WebRTC requests, slips out over your own connection instead, so a test can look fine while quietly exposing your real IP.

Three checks catch the common leaks:

• IP consistency. Request httpbin.org/ip through the proxy several times and confirm the origin IP is always the proxy, never your own. If your real IP appears even once, something is routing around the proxy.
• DNS resolution. Make sure DNS queries resolve through the proxy. With SOCKS5, use curl’s --socks5-hostname flag so the hostname is resolved by the proxy, not on your machine:

• Browser WebRTC. If you test inside a browser, WebRTC can reveal a local IP independently of the proxy. The Proxy-Cheap browser extensions include WebRTC protection for exactly this reason.

Run the IP consistency check across a dozen requests. A proxy that returns its own IP every time, with no trace of yours, has passed the leak test.

Method 7: Test authentication and rotation

Two proxy features deserve their own test: authentication and rotation.

Authentication. The cleanest signal is the proxy’s own response. Run curl with -v and watch the handshake, or let Python surface the error for you:

A clean JSON result means the credentials work. A 407 Proxy Authentication Required means the proxy is reachable but the username or password is wrong, or the request came from an IP that is not on the allowlist. If you use IP allowlisting, test from the exact machine whose IP you added in the dashboard, because a 407 there almost always means the sending IP does not match the one on file.

Rotation. Rotating residential and mobile proxies hand out a new exit IP per request through the gateway. To confirm rotation is working, send several requests and watch the IP change:

Each line should show a different origin IP. If the IP never changes, you are likely on a static product or a sticky session, which holds one IP for around 30 minutes by design. For rotation inside a script, see how to rotate proxies in Python.

Method 8: Test proxies in bulk with a Python script

For more than a handful of proxies, a script is the only practical option. The function below sends one request through a proxy, measures the round trip, and returns the status, exit IP, and latency, or the error type if it failed. It uses the requests library (pip install requests).

A passing proxy prints a clean result:

A failing one returns the exception name, usually ProxyError for a bad credential or unreachable proxy, or ConnectTimeout for one too slow to answer. From here you can scale the function: load a list from a file, run it across threads with concurrent.futures, and write results to CSV to sort by latency and success rate. That is the practical version of the "custom software" other guides mention but rarely show.

Why a proxy test fails, and how to fix it

When a test fails, the symptom usually points straight to the cause:

• 407 Proxy Authentication Required. Wrong username or password, or the request came from an IP that is not on your allowlist. Re-copy the credentials from the dashboard, and if you use IP authentication, confirm the sending IP matches.
• Connection timeout. The proxy did not answer in time. Check the host and port, raise your timeout, and confirm the proxy is still active in your plan.
• Connection refused or a protocol error. You are likely using the wrong protocol. Try http:// first, since it is the most compatible, and switch to SOCKS5 only when you need it. Confirm the product supports the protocol you are sending.
• Works in curl, fails in code. Credentials are probably embedded in the target URL, or the proxy scheme is wrong. Keep credentials in their own field and set the proxy scheme to http://.
• Right IP, wrong country. The exit location does not match the order. Re-check the gateway or the specific IP you selected, and confirm your plan covers the country you need.
• Passes the generic check, fails on your target. A generic endpoint says nothing about one specific site. Always run the final test against your real target URL, not just httpbin.org. If a datacenter IP struggles on a protected site, switch that job to a residential or mobile IP, which routes through a real consumer or mobile carrier connection.

The pattern across all of these: read the status code first, then the exit IP, then the headers. Those three signals locate almost every proxy problem in under a minute.

Which Proxy-Cheap proxy fits your use case?

The test methods are the same across products, but the result you should expect depends on the proxy type. Match the product to the job before you test:

Match the proxy type to the job before testing: rotating residential for volume, static residential or ISP for stable sessions, datacenter for throughput, mobile for carrier IPs.

A quick way to choose: if the target varies content by visitor or location, test a residential or mobile IP. If the target is public and you care most about speed and volume, test a datacenter IP. If you need the same IP to persist, test a static residential or ISP proxy.

Proxy-Cheap covers all of these on pay-as-you-go and per-IP plans, with no setup costs and cancel anytime. Whether you run a one-off check or test thousands of mobile and unlimited bandwidth proxies in a script, every product is testable with the exact methods in this guide. Pick the type that matches your target, generate credentials in the dashboard, and run the curl or Python test before you commit it to a production job.