You bought proxies an hour ago. The dashboard says active. Does that mean they work?
Not yet. How to test a proxy properly takes five curl commands and about 15 minutes. Check the exit IP, the headers, DNS, speed over 20 connections and the page you bought it for, before a refund window that can be 24 hours closes.
We ran every check from our server through a live exit node. The one that caught a block is the one most buyers skip.
Why test a proxy on day one?
Because proxy refunds expire fast, and most die once you’ve used a little data. Here’s what three providers allow, checked on 23 October 2026.
| Provider | Window to test | What kills the refund |
|---|---|---|
| Webshare | 48 hours after purchase | More than 0.1 GB used on rotating residential, or 1 GB on proxy server and static residential plans |
| IPRoyal residential | 24 hours, for connection problems support can’t fix | More than 100 MB of your data used |
| Bright Data | A $2 trial credit for 7 days, plus $5 once you add a card | No refund route; residential needs an approved business account first |
Two of the three give you about a day. The test isn’t a weekend project. It’s the first thing you do after checkout.
The good news: testing costs almost no data. We counted the bytes, and 20 IP checks used 134 KB, about 6.7 KB each with the TLS handshake. One run of the script below stays well under 1 MB unless your target page is huge.
One habit saves real data on bandwidth plans. A news homepage cost us 397 KB raw and 75 KB with curl’s --compressed flag, five times less for the same page.
Want to rehearse before paying anything? Webshare’s free plan gives you 10 shared proxies and 1 GB a month, plenty for every check here. Our IPRoyal vs Webshare comparison covers what the paid plans cost after that.
Provider links on this page are affiliate links: if you buy through one, DroidCrunch may earn a commission. It doesn’t change a single test result.
How we ran these tests (and what we didn’t)
Everything here ran on 23 October 2026 from our Linux server with curl 8.14.1. The remote proxy was a Tor exit node: free, with real public IPs in other countries, so every lookup below hit a real outside service.
To show header leaks on demand, we wrote a small lab proxy with three modes. One adds our real IP to every request, one adds only a Via header, and one adds nothing.
What we didn’t do: buy a paid plan for this post, or run the browser checks in a browser. That section says so. Every number you’ll see came out of our terminal.
The proxy test checklist: seven checks in order
Run the checks in this order, because each one assumes the last one passed. There’s no point timing a proxy that’s leaking your IP.
How to test a proxy in seven checks
From exit IP to your real target, with nothing but curl
-
Step 1 of 7
Confirm the exit IP
Ask api.ipify.org for your IP with and without the proxy. Two different answers means traffic is going through it. The same answer means it isn’t.
-
Step 2 of 7
Read the IP's record
Look the exit IP up on ip-api.com. Check the country, the network (ASN) and the hosting flag against what you paid for.
-
Step 3 of 7
Run a header leak test
Send a request to the azenv.net proxy judge over plain HTTP. Your real IP in any line is an instant fail.
-
Step 4 of 7
Check where DNS resolves
Use
socks5h://for SOCKS proxies and read curl’s verbose output. You want remotely resolved. -
Step 5 of 7
Browser only: WebRTC and DNS pages
If the proxy will run in a browser, open a WebRTC leak test and a DNS leak test through it. Neither should show your real IP or your ISP’s resolvers.
-
Step 6 of 7
Time 20 fresh connections
Measure time to first byte 20 times and read the median and the slowest 10%. One fast ping proves nothing.
-
Step 7 of 7
Hit your real target
Fetch the page you bought the proxy for and read the body, not the status code. Then check that rotation or sticky sessions behave.
Here’s the whole checklist as one script. Paste in your proxy and the page you care about; it takes http://, https:// and socks5h:// proxies.
#!/usr/bin/env bash
# Usage: ./proxy-test.sh 'http://user:pass@host:port' 'https://your-target.com/page'
P="$1"; T="$2"
echo "1) Real IP: $(curl -s https://api.ipify.org)"
echo " Proxy IP: $(curl -s -x "$P" https://api.ipify.org)"
echo "2) What IP databases say:"
curl -s -x "$P" "http://ip-api.com/json/?fields=country,city,isp,as,proxy,hosting"; echo
echo "3) Headers the site receives:"
curl -s -x "$P" http://azenv.net/ | grep -E 'REMOTE_ADDR|VIA|FORWARDED|CLIENT_IP'
echo "4) Speed, 20 fresh connections:"
for i in $(seq 20); do
curl -s -o /dev/null -m 30 -x "$P" -w '%{http_code} %{time_starttransfer}\n' https://api.ipify.org
done | sort -k2 -n | awk '{t[NR]=$2; ok+=($1==200)} END {printf " %d/20 OK, median %.2fs, p90 %.2fs\n", ok, t[int(NR/2)], t[int(NR*0.9)]}'
echo "5) Your real target:"
curl -s --compressed -A 'Mozilla/5.0' -x "$P" -o /tmp/target.html -w ' HTTP %{http_code}, %{size_download} bytes\n' "$T"
grep -o -i -m1 -E 'captcha|access denied|unusual traffic|<title>[^<]*' /tmp/target.htmlThis is what it printed through our Tor exit, aimed at an Amazon product page. We’ve hidden our server’s real IP.
1) Real IP: [hidden]
Proxy IP: 185.220.101.133
2) What IP databases say:
{"country":"Germany","city":"Brandenburg an der Havel","isp":"Stiftung Erneuerbare Freiheit","as":"AS60729 Stiftung Erneuerbare Freiheit","proxy":true,"hosting":true}
3) Headers the site receives:
REMOTE_ADDR = 185.220.101.133
4) Speed, 20 fresh connections:
20/20 OK, median 1.43s, p90 1.53s
5) Your real target:
HTTP 200, 3781 bytes
CaptchaFour checks passed. The fifth failed, and the status code said everything was fine. We’ll get to why.
Is the proxy hiding your IP, and is it the IP you paid for?
Check 1 is a yes-or-no answer: if the proxy IP matches your real IP, nothing is going through the proxy.
That’s usually setup, not a dead server: a missing scheme in the proxy string, a whitelist that doesn’t include your server, or a tool that ignores the proxy setting. Our guide to common proxy errors walks through each one.
Check 2 is where buyers get caught out. Our exit came back as hosting:true, on a network registered to a German foundation. That’s correct for Tor. It would be a problem on a residential plan.
Why? A residential IP belongs to a home connection, and IP databases mark it that way. If your residential proxies keep coming back as hosting IPs, you’re paying residential prices for datacenter traffic. Our residential vs datacenter proxies guide explains why that difference decides whether sites trust you.
Real-world tip: Don’t panic over the city. ip-api put our exit in Brandenburg an der Havel, while ipwho.is put the same IP in Berlin, about 60 km away. Targets check country and network. City is a database’s best guess.
One more signal came free. Two popular lookup sites, ipinfo.io and ifconfig.me, answered our exit with 403 Forbidden. If a lookup site blocks your IP, assume stricter sites will too.
Proxy anonymity test: which headers give you away?
A proxy anonymity test shows which headers your proxy adds to your requests. A proxy judge such as azenv.net prints them straight back to you.
Our lab proxy ran the same request in each of its three modes. Here’s what the judge saw:
- Transparent:
HTTP_X_FORWARDED_FORcarried our real IP, andHTTP_VIAnamed the proxy. The site knows who you are and that you’re on a proxy. - Anonymous: only
HTTP_VIA. Your IP is hidden, but the proxy announces itself. - Elite: only
REMOTE_ADDR, the exit IP. To the site, it’s an ordinary visitor.
Here’s the catch: run this test over http://, not https://.
Through HTTPS, our leaky proxy couldn’t add a thing, because it only relays an encrypted tunnel. An HTTPS header echo showed four clean headers while the same proxy leaked our real IP on plain HTTP. Test on an HTTPS page, and a transparent proxy can look elite.
Our take: a transparent proxy is a refund, full stop. An anonymous one is fine for scraping public pages. For logged-in accounts, it’s a fail, because that Via header tells the site exactly what you’re doing.
DNS and WebRTC: the leaks that skip the proxy
A DNS leak happens when your device looks up the site’s address itself, so your ISP’s resolver sees every domain you visit, proxy or not.
With curl, the fix is one letter. Use socks5h:// instead of socks5://, add -v, and read the connect line: ours said SOCKS5 connect to api.ipify.org:443 (remotely resolved).
Without the h, curl reported locally resolved, so our own server did the lookup. Our HTTP vs SOCKS5 explainer covers why HTTP proxies don’t have this problem.
Browsers are where the next two leaks live. We didn’t run these in a browser for this post, so this part is from the browsers’ own documentation.
- DNS in a browser: Chrome resolves through a SOCKS5 proxy on its own. Firefox needs Proxy DNS when using SOCKS v5 ticked in its connection settings. Then open any DNS leak test page through the proxy and look for your ISP’s name.
- WebRTC: video-call code can send UDP traffic around an HTTP proxy and expose your IP. Chrome’s
WebRtcIPHandlingpolicy set todisable_non_proxied_udpblocks it. In Firefox, setmedia.peerconnection.enabledto false.
Running many browser profiles? A good anti-detect browser handles WebRTC per profile, so you don’t touch these settings at all.
Proxy speed test: why one ping lies
Time 20 fresh connections and read two numbers: the median and the 90th percentile. A single request tells you nothing about the slow ones that stall a job.
Our direct connection’s median time to first byte was 0.117 seconds. Through Tor it was 1.42 seconds, with the slowest 10% at 1.60 seconds. That’s slow but steady, because Tor routes every request through three relays. All 20 requests came back with a 200.
Steady matters more than fast. If your p90 is more than double your median, part of the pool is dragging. That slow part sets the pace of every batch job.
Then test at the concurrency you’ll really use. We fired 50 requests, 10 at a time, and all 50 succeeded: median 1.20 seconds, worst 1.99. Plans often cap threads, so a proxy that’s quick one at a time can still choke at 50.
Common mistake: Testing from your laptop, then running the job on a server in another country. Distance to the proxy gateway is part of every number above, so run the test from the machine that will do the work.
The test that matters most: your real target
Fetch the page you bought the proxy for, and judge it by the body, not the status code.
Remember the check that failed? Our Amazon request came back HTTP 200, a success by the status code. The page was 3,781 bytes and contained the word Captcha. Our server’s own datacenter IP got the identical page with no proxy at all.
So a 200 can be a block page in disguise. Record the size of a real page once, then flag any response that’s a fraction of it, or that contains captcha or access denied. Our guide to scraping Amazon without IP bans covers what gets past that wall.
While you’re on the target, check rotation. Ten requests with no session label all came from one IP. Then we added session labels to the username, the way most providers do: session one held one IP for three requests, session two held another.
That’s the behaviour to confirm. A rotating plan should change IP when you ask it to, and a sticky session should hold it for the time you paid for. Not sure which one your job needs? Our rotating vs static proxies guide settles it.
Pass, fail or switch: what your results mean
Every result points to one action, and most failures inside the refund window mean a ticket, not a workaround.
| What you saw | What it means | What to do |
|---|---|---|
| Proxy IP equals your real IP | Traffic isn’t using the proxy | Fix the proxy string or whitelist, then retest |
| hosting:true on a residential plan | You may have datacenter IPs | Send support the IP and ASN; ask for a refund inside the window |
| Your IP in X-Forwarded-For | Transparent proxy | Refund. Don’t use it for anything |
| Via header only | Anonymous, not elite | Fine for public scraping, not for accounts |
| DNS locally resolved | DNS leak | Switch to socks5h or turn on remote DNS |
| p90 more than double the median | Uneven pool | Try another region or gateway before deciding |
| 200 but a tiny or captcha page | Blocked on your target | Move up a proxy type, such as datacenter to residential |
Which provider should you put through this first? Webshare if you want to rehearse on the free plan, because the 10 free proxies cost you nothing to fail. IPRoyal if you need residential IPs without a subscription: pay-as-you-go traffic was $7.35 a GB for 1 GB on 23 October, and it doesn’t expire.
Running a business with real volume? Bright Data is worth the paperwork, but its residential network opens only after a human-reviewed KYC check. Start that before you need the IPs. Our Bright Data review covers the rest of the account.
Frequently Asked Questions
Are free online proxy checkers safe to use with a paid proxy?
Only the kind that reads your request. A proxy judge like azenv.net sees your proxy’s IP and nothing else. Never type your proxy username and password into a web form that tests it for you. If you already have, change the password in your provider’s dashboard.
How often should you test a proxy after the first day?
Rerun the script whenever a plan renews, once a week on long-running jobs, and the moment your block rate climbs. Static and ISP IPs can get flagged weeks after they were clean, and a renewal can hand you a different subnet than the one you tested.
Can a proxy test tell me if an IP is blacklisted?
Partly. The hosting and proxy flags, plus 403s from lookup sites, show how databases see the IP. Spam blacklists matter for email, not scraping. The only blacklist that counts for your job is your target’s, and the real-target check is the test for that.
Do I need to test a VPN the same way?
Mostly. The exit IP, DNS and WebRTC checks apply as written. The header test matters less, because a VPN tunnels all your traffic instead of relaying single requests. A VPN’s IP will usually show hosting:true, which is normal for one.
Why does a proxy pass in curl but fail in the browser?
The IP is only one signal. Browsers also send cookies, a fingerprint, a time zone and a language. A German exit IP with an Indian time zone and a logged-in Google cookie looks odd, even when every curl check passes.
How do I test a SOCKS5 proxy with curl?
Use the same script with socks5h://user:pass@host:port as the proxy. Expect the header test to show only REMOTE_ADDR, because SOCKS5 doesn’t edit HTTP headers. If you see a Via or X-Forwarded-For line, something else in your chain is adding it.
What success rate should a paid proxy hit?
On your real target, we treat anything under 95% as a fail worth a support ticket. A residential pool will be slower than datacenter IPs, which is fine. Failed and blocked requests aren’t, because on bandwidth plans you pay for every one of them.
Run the script before you run the job
Testing a proxy takes 15 minutes and under 1 MB of data. It’s the only way to know what you bought before the refund window shuts.
Scraping public pages? An anonymous proxy that passes the speed and target checks is enough. For accounts, accept nothing short of elite, with clean DNS and WebRTC leak checks. Whatever the job, trust the body of your target page over its status code.
Next step: copy the script, run it against the proxy you bought today, and send support the output if anything fails.
