How to Test if a Proxy Is Working

The most basic check is to ask an echo service what IP it sees. Do it once without the proxy to learn your real address, then again through the proxy. If the second result differs and matches your proxy's exit IP, traffic is flowing. On the command line, curl passes proxy details with the -x (lowercase, case-sensitive) flag:

# your real IP, no proxy
curl https://ipinfo.io/json

# through an HTTP proxy
curl -x http://USER:PASS@HOST:PORT https://ipinfo.io/json

# ip-api.com returns geo + carrier fields too
curl -x http://USER:PASS@HOST:PORT https://ip-api.com/json

Both ipinfo.io and ip-api.com return JSON you can read at a glance. ip-api.com requires no key for its free endpoint and documents a limit of 45 requests per minute per IP, which is plenty for spot checks. If you prefer the browser, open the same URLs in a browser configured to use the proxy and read the reported IP. For the full command-line reference, including SOCKS and authentication, see our guide on testing a mobile proxy with curl.

A working IP is not the same as the right IP. If you paid for a UK mobile exit, the test should show a UK location on a mobile carrier's network, not a datacenter in another country. The most reliable signal here is the ASN (Autonomous System Number) and the organization that owns the IP range.

Both echo services above return this. ipinfo.io reports an asn and organization name; ip-api.com returns as, asname, isp, plus latitude, longitude and timezone. ip-api.com also exposes a boolean mobile field that is true for many cellular ranges, and hosting and proxy flags worth glancing at.

If the ASN points at a hosting provider, you are on a datacenter IP regardless of what the listing claimed. That distinction is the whole point of a mobile proxy: the exit is a real 4G/5G carrier address, so the ASN reads as a mobile operator and inherits the trust that carrier-grade NAT ranges carry.

A proxy can pass traffic and still advertise itself, or worse, forward your real IP in a request header. To see exactly what a server receives, send a request through the proxy to an endpoint that echoes headers back, such as httpbin.org/headers:

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

Two headers matter most. Via announces that a proxy is in the path, and X-Forwarded-For (XFF) can carry the original client IP. Proxy anonymity is usually described in three levels based on these:

• •Transparent: sends both Via and your real IP in X-Forwarded-For. The site knows you are proxied and who you are.
• •Anonymous: reveals a proxy is in use (via headers) but does not leak your real IP.
• •Elite / high-anonymity: forwards neither header, so the request looks like an ordinary direct connection.

For anything sensitive you want elite behavior: no Via, and no X-Forwarded-For containing your real address. If your real IP appears anywhere in that JSON, stop and fix the setup before using the proxy for real work.

Header checks catch the HTTP layer, but two common leaks happen outside it. A DNS leak is when name lookups go straight to your ISP's resolver instead of through the proxy, quietly tying activity back to you. A WebRTC leak is a browser issue: the WebRTC API can query STUN servers over UDP and report your real public and local IPs, bypassing the HTTP path the proxy controls.

Test these in a browser that is actually using the proxy:

• •browserleaks.com/webrtc and browserleaks.com/dns - dedicated WebRTC and DNS leak pages, alongside IP, canvas, and WebGL fingerprint tools.
• •dnsleaktest.com - a focused standard and extended DNS leak test that lists the resolvers your requests exit through.
• •whoer.net - an anonymity overview that rolls IP, DNS, WebRTC, timezone, and User-Agent consistency into one page.

A clean result shows the proxy's IP everywhere and no real-IP disclosure in the WebRTC or DNS sections. If WebRTC exposes your real address, disable or route WebRTC in your browser or antidetect profile; if DNS resolves through your ISP, switch to a SOCKS5 setup with remote resolution (socks5h://) or a browser that sends DNS through the proxy.

Once the IP is correct and clean, check that it is usable. curl can time a request end to end so you can gauge latency and spot a flaky connection across a few runs:

curl -x http://USER:PASS@HOST:PORT -o /dev/null -s \
  -w "code:%{http_code} time:%{time_total}s\n" https://ipinfo.io/json

Mobile proxies naturally show more variable latency than datacenter IPs because they ride a real cellular link, so judge stability across several requests rather than a single number. The more important skill is telling a dead proxy from a blocked one, because they look similar but need opposite fixes:

The tell is simple: if a neutral endpoint like ipinfo.io works but your target does not, the proxy is alive and the site is blocking it. That points you toward rotation, a fresh IP, or a higher-trust network rather than debugging the proxy connection. Rotating to a clean carrier IP is one reason people move to mobile exits in the first place.

Sources & tools referenced

• • ip-api.com - JSON API documentation (fields, ASN, mobile flag, rate limit)
• • ipinfo.io - Developer docs (IP, ASN, and geolocation responses)
• • BrowserLeaks - WebRTC and DNS leak tests
• • DNSLeakTest - standard and extended DNS leak tests
• • Whoer.net - anonymity and consistency overview
• • curl - manual page (-x/--proxy, SOCKS, timing options)