How to check if a proxy works (and whether it leaks your IP)

A proxy can answer and still leak your real IP. Check the exit, DNS, WebRTC, protocol, and blocklists before you put the endpoint in production.

How to check if a proxy works (and whether it leaks your IP)

A proxy “working” means two different things. The gateway must accept your client and fetch a page. The rest of your device must also stop exposing the real IP. Plenty of endpoints pass the first test and fail the second.

Do this check before you scale a plan. Do it again after rotation. Pools change. Firmware on a phone browser changes. A passing test yesterday is not a contract.

01Confirm the exit IP first#

Point a simple client at the proxy. Use the same protocol and auth you will use in production. Then request a page that echoes the client IP.

The proxy checker tests whether the endpoint answers from Top Proxy's server and reports the first protocol that succeeds. It automatically tries SOCKS5, HTTP, SOCKS4 and HTTPS in that order, so a passing result does not prove that every protocol works. The check does not configure your browser or test its DNS, WebRTC or direct connections. If your provider uses an IP allowlist, a server-side failure may mean that the checker server is not allowed; verify the same endpoint from your authorized client before deciding it is dead.

Open My IP through the same proxy. Read the country, the ASN, and the hosting versus residential label if the page shows one. Compare that to what you bought. A “US residential” product that exits on a cloud ASN is the wrong product, not a settings issue.

Repeat the lookup after you rotate. A mixed pool can hand you a different country on the next session id. If you paid for US proxies, the second sample should still be in the United States.

02Look for leaks around the proxy#

A proxy only covers traffic that your client sends through it. Everything else can still use your real network.

DNS behavior depends on the protocol and client. For curl, socks5:// resolves destination names locally, while socks5h:// asks the SOCKS5 proxy to resolve them. A separate DNS resolver changes who receives your lookup; it does not prove that the lookup travels through your proxy. Check the browser's own proxy and DNS settings, then run a DNS leak test in that same profile. Compare the result with the resolver you intended to use. See the curl proxy documentation for scheme-specific behavior.

WebRTC can use connection paths outside an HTTP proxy. Inspect the candidate addresses in a WebRTC test in the actual browser profile. If your original public IP appears, review that browser's WebRTC privacy settings and repeat the test. Browser restrictions and address masking vary, so a proxy checker result alone cannot establish that WebRTC is covered. MDN explains ICE candidate addresses and privacy.

IPv4 and IPv6 need separate observations. An IPv4 connection to an HTTP or SOCKS gateway does not imply that the destination connection is IPv4, and a device having IPv6 does not by itself mean that a site bypasses the proxy. Test IPv4 and IPv6 echo endpoints through the actual client, then inspect bypass rules and applications that can connect directly. Choose a provider that supports the destination address family your task needs.

Applications can bypass system proxies. A native app may ignore the OS setting and connect directly. Configure a proxy through the method that the application actually supports, then test that application. See SOCKS5 vs HTTP if the client supports both.

03Check reputation, not only reachability#

An IP can fetch a page and still be useless for your job. Hosting flags, blocklists, and prior abuse all live on the address.

If the task is mail, sign-up, or anything that other people have already burned, run the exit through IP blacklist. A listing is a warning. It is not a moral judgment. Shared residential pools pick up listings. Dedicated datacenter IPs pick them up too.

If the task is scraping, fetch the real target URL, not only an echo service. Some hosts allow https://httpbin.org and still block your catalog page. Save the status code, the body length, and whether a challenge appeared. That is the only score that matters.

If the task is geo QA, compare the page you wanted with the page you got. Currency, language, and catalog should match the country you bought. A correct ASN with the wrong storefront means the site is using another signal.

04Make the check repeatable#

Write the steps down. Same client, same auth, same echo URL, same target URL, same leak pages. Run them when you buy. Run them when you rotate. Run them when a job starts failing.

Record the exit IP, ASN, protocol, and whether DNS or WebRTC showed your real address. When a vendor replaces a port, you will know what changed.

Do not skip auth mistakes. User and password in the wrong field look like a dead proxy. IP-allowlist auth looks like a dead proxy from a new office network. Fix auth before you open a ticket.

Before scaling a purchase, compare residential proxies and datacenter proxies against the protocol, country and session behavior you just tested. Confirm those requirements in the provider's published offer, then start with a small plan.

A passing server check establishes reachability for that test. A working setup also needs the actual client to use the expected exit and return the intended target page, with separate checks for connection paths you want covered. Record each result rather than treating one green status as a complete privacy guarantee.