How to test if a proxy is working (3 reliable ways)

You have a proxy address and a suspicion. Maybe it came from a provider, maybe from a colleague, maybe from a free list of questionable parentage. Before you wire it into anything, you want two answers: does it work, and does it actually change your IP? Here are three ways to get them, from easiest to most hands-on.

Method 1: an online checker (10 seconds)

The fastest route is a browser-based tool. Paste the proxy into our free proxy checker, pick the protocol, and hit check. You get four facts back: whether it connected, the exit IP, the country, and the response time.

The exit IP is the important one. If the proxy works, that address belongs to the proxy, not to you. The country tells you whether the geolocation matches what you paid for, and the response time tells you whether this proxy will be pleasant or painful to work through.

One caveat worth knowing: an online checker tests from its own server, not from your machine. If your provider restricts access by IP allowlist, the checker's server may be refused while your own machine sails through. Which brings us to method two.

Method 2: curl (30 seconds)

If you have a terminal, curl tests a proxy from exactly where your traffic will originate. The pattern is one flag:

# HTTP proxy
curl -x http://user:[email protected]:8080 https://api.ipify.org

# SOCKS5 proxy
curl -x socks5://user:[email protected]:1080 https://api.ipify.org

# SOCKS5 with DNS resolved on the proxy side
curl -x socks5h://user:[email protected]:1080 https://api.ipify.org

The target, api.ipify.org, simply echoes back the IP address that reached it. If the command prints the proxy's exit address, your proxy works. If it prints your own IP, something in the chain is being bypassed. Add -w "%{time_total}\n" if you also want the request time, and -v when you need to see the handshake to debug a failure.

A word on that socks5h variant: the h means the proxy resolves domain names instead of your machine. If a SOCKS proxy fails with a DNS error using plain socks5, the h version often fixes it.

Method 3: your browser or system settings (2 minutes)

Sometimes you want to experience the proxy the way a user would. Set it system-wide (or in Firefox, which has its own proxy settings independent of the OS), then visit any what-is-my-ip site. If the shown address is the proxy's, everything on that browser is flowing through it.

This method is slower but it catches problems the quick checks miss, like a proxy that works for one request and then throttles, or one that breaks certain sites. It is also the only sensible way to test whether streaming or region-locked content behaves through the proxy.

Reading the results like someone who has been burned before

It connects, but slowly. Run the test three times before judging. First requests through a cold proxy include connection setup that later requests skip. If it stays above three seconds, the proxy is far away or oversold, and your throughput will suffer accordingly.

The exit IP matches the proxy host. Normal for simple proxies. For rotating gateways, the exit will differ from the gateway address and should change between runs. If a rotating proxy returns the same exit twice, the rotation may be per-session rather than per-request. Check the provider docs before assuming it is broken.

The country is wrong. Geolocation databases lag reality. One wrong lookup means little. Three different tools agreeing that your Paris proxy lives in Warsaw means a support ticket.

It fails outright. The error message is your friend. A refused connection points at a dead server or wrong port, an auth error means credentials, a timeout suggests a firewall or allowlist. We keep a full decoder in common proxy errors and how to fix them.

Make it a habit

Proxies die quietly. Providers rotate ranges, servers get rebooted, subscriptions lapse. The ten seconds it takes to check a proxy before a scraping run is the cheapest insurance in this entire field. Test first, then build.