How to Check Proxy Quality: IP, Fingerprint, DNS and WebRTC Leak Tests (2026)

Not all proxies are equal. A proxy might connect successfully but still leak your real IP through WebRTC, show a datacenter ASN instead of a mobile carrier, or fail reputation checks that ad platforms run automatically.

Before using any proxy for Facebook Ads, TikTok, scraping, or multi-accounting — test it. This guide covers every meaningful quality check, in the order you should run them, with the specific tools and expected results for each.

Test 1 — Basic IP and Carrier Check

The first check: does the proxy IP belong to a real mobile carrier?

Tools to use:

• ipwho.is — shows IP, ASN, org, country
• ip.sb — simple IP display
• The built-in checker at proxygrow.com/en/#checker

What to look for:

If org shows a cloud hosting company, you have a datacenter proxy disguised as mobile. Real mobile proxies show the actual carrier name.

You can run this from the command line as well:

# Through your proxy
curl -x socks5h://user:pass@proxy-host:port https://ipwho.is | jq

# Expected fields for a Kyivstar Ukrainian mobile proxy:
# "type": "ipv4"
# "country": "Ukraine"
# "connection": {"asn": 15895, "org": "Kyivstar PJSC", "isp": "Kyivstar", "type": "mobile"}

If connection.type returns anything other than "mobile" (e.g., "business", "hosting", "residential") — the proxy is not what it claims to be.

Test 2 — WebRTC Leak Test

WebRTC is a browser API that can expose your real IP even when a proxy is active. Platforms like Facebook and TikTok use JavaScript WebRTC checks to detect proxy users.

Tools:

• browserleaks.com/webrtc
• ipleak.net

What to check:

Open the tool through your proxied browser. You should see:

• Public IP = your proxy IP (the mobile carrier IP)
• Local IP = either the proxy IP or nothing (if WebRTC is disabled)
• STUN-derived IP = the proxy IP, not your home IP

If you see your real home IP in WebRTC: the proxy is leaking. Fix this by:

1. Disabling WebRTC in your anti-detect browser settings
2. Setting WebRTC to "Fake" in AdsPower, Dolphin, or GoLogin
3. Using a browser extension like uBlock Origin with WebRTC blocking
4. For Firefox: about:config → media.peerconnection.enabled → false

A proper mobile proxy will show the carrier IP in both the HTTP and WebRTC checks when WebRTC spoofing is active in the anti-detect browser. If the anti-detect browser claims to spoof WebRTC but you still see your real IP — the browser's WebRTC patch is broken (it happens after major Chromium upstream merges).

Why WebRTC matters more than the average proxy leak: most leaks (DNS, IPv6) expose location but not identity. WebRTC exposes your home IP, which is the most stable identifier you have. If two of your ad-account profiles both leak the same home IP via WebRTC, Facebook links them through that IP regardless of how clean the proxy layer is.

Test 3 — DNS Leak Test

A DNS leak means your DNS queries go through your real ISP instead of the proxy, revealing your actual location.

Tool: dnsleaktest.com — run the "Extended test"

Expected result: DNS servers should appear in the same country as your proxy. If you see your home country's ISP DNS servers — you have a DNS leak.

Fixes:

• Use SOCKS5 with the socks5h:// scheme (the h means "resolve through proxy"). In Python requests: proxies = {'http': 'socks5h://...', 'https': 'socks5h://...'}. Without the h, the client resolves DNS locally before connecting.
• In a browser profile with "Proxy DNS" or "Use proxy for DNS lookups" — enable it
• Configure system DNS to 1.1.1.1 or 8.8.8.8 when using IKEv2 VPN
• In VLESS + Xray setup: ensure "domainStrategy": "UseIP" is set in the outbound config so DNS happens at the egress
• For Chrome with native proxy support, set the --proxy-server flag with SOCKS5 and add --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE proxy-host"

DNS leaks are particularly nasty because they're silent — the proxy works, the page loads, but your home ISP's DNS resolver logs every domain you visit through the proxy.

Test 4 — IP Reputation Check

IP reputation tells you if the proxy IP has been flagged for spam, abuse, or blacklisted by ad platforms.

Tools:

• mxtoolbox.com/blacklists — checks common email/IP blacklists (Spamhaus, SORBS, Barracuda)
• scamalytics.com — proxy and fraud risk score
• ipqualityscore.com — proxy detection score
• abuseipdb.com — community-reported abuse history

What you want:

• Fraud score: below 30/100 is good, below 50 is acceptable
• No blacklist hits on major lists (Spamhaus SBL/XBL, SORBS, Barracuda)
• is_proxy / is_vpn flags should be false or low confidence
• AbuseIPDB confidence-of-abuse: under 25%

Mobile carrier IPs from active SIM cards rarely get blacklisted because they're shared by real mobile users via CGNAT. This is why they have better reputation than residential or datacenter proxies. That said, some mobile carrier ranges are flagged by IPQS as "high confidence VPN" even when they aren't — IPQS aggressively flags any IP that has ever appeared in known proxy lists, which inevitably includes carrier ranges that proxy providers have used. Treat IPQS scores on mobile carriers as a softer signal than on datacenter IPs.

What to do if reputation is poor:

1. Rotate the IP — mobile proxies rotate within seconds; you'll get a different exit IP from the carrier's CGNAT pool
2. If reputation is consistently bad across 5+ rotations, the modem's NAT pool is contaminated — request a different modem from the provider
3. Cross-check with one more reputation source — single-source reputation reports have high false-positive rates on mobile IPs

Test 5 — TCP/IP Fingerprint (OS Fingerprint)

Advanced platforms (and some DPI systems) check the TCP fingerprint — how your connection looks at the packet level. A server running a proxy will have a Linux server TCP stack. A real mobile device running Android will have a different TCP profile.

Tool: browserleaks.com/ip (look at the "TCP/IP Fingerprint" section), p0f3.com, or Wireshark for manual analysis.

What to look for: If the fingerprint shows Linux 3.x/4.x — that's a server. A real mobile proxy with pOSfp technology will show a fingerprint matching a mobile OS (Android 13/14, iOS 17).

ProxyGrow uses Passive OS Fingerprint (pOSfp) spoofing via the proxygrow-minirouter component, which modifies TCP/IP parameters at the kernel level to match real mobile device signatures. Without pOSfp, the kernel emits TCP packets with the default Linux MSS (1460), window scale (7), and SACK ordering — a configuration no Android phone has ever produced. With pOSfp, the TCP handshake parameters match exactly what an Android 14 device on a 4G connection would emit.

This level of detail matters mostly for sophisticated anti-fraud stacks (large e-commerce, ad networks running their own DPI) and is not relevant for casual scraping. But if you've been flagged with no obvious cause on Facebook or TikTok, TCP fingerprint mismatch is a common silent killer.

Test 6 — Speed and Stability

A proxy that leaks nothing but drops connections every 30 seconds is still unusable.

Test with:

• fast.com — speed test through the proxy
• speedtest.net — if accessible through the proxy
• A long-running curl test: for i in {1..50}; do curl -w "%{http_code} %{time_total}\n" -s -o /dev/null -x socks5h://user:pass@proxy:port https://example.com; sleep 2; done

Acceptable benchmarks for mobile proxies:

• Shared plan: 10–50 Mbps download, stable connection
• Premium plan: 50–150 Mbps download, stable connection
• Latency: 30–120 ms is normal for mobile carrier networks
• Packet loss: under 1% during a 5-minute test
• Connection failure rate: under 5% across 50 sequential requests

High latency (>300 ms) or frequent disconnections usually indicate poor carrier signal at the proxy location. Contact support to get an IP rotation — a new IP session may have a better signal.

Test 7 — HTTPS and Certificate Validation

Some malicious or misconfigured proxies do TLS interception (man-in-the-middle) to inject ads or harvest credentials. Verify the certificate chain is intact:

curl -x socks5h://user:pass@proxy:port -v https://github.com 2>&1 | grep -E "subject:|issuer:"
# Expected:
# subject: CN=github.com
# issuer: CN=Sectigo ECC Domain Validation Secure Server CA

If the issuer is something other than the real CA (e.g., Proxy Inc, Self-Signed), the proxy is intercepting TLS — do not use it. Real residential and mobile proxies operate at the TCP/SOCKS5 layer and never touch TLS.

Quick Checklist

Before using a proxy for any serious task, verify:

• IP belongs to a real mobile carrier (not datacenter)
• connection.type returns "mobile"
• WebRTC shows proxy IP or is blocked
• DNS resolves through proxy country
• Reputation score is low (not blacklisted)
• TCP fingerprint matches a mobile OS (if pOSfp is offered)
• Connection is stable at acceptable speed
• HTTPS certificates are not intercepted

All these checks take under 5 minutes. Skipping them can cost you a banned ad account or burned domain.

Common False Positives and How to Read Them

Some checkers will flag even pristine mobile proxies as "suspicious" because they aggressively bucket entire carrier ASNs as "VPN provider" once any proxy reseller uses that range. This is especially common with ipqualityscore.com and ipdata.co for Eastern European carriers. Calibrate your expectations:

• One source flags as VPN, others say mobile: likely a false positive. Trust the consensus.
• Multiple sources flag as datacenter: real problem — the proxy is not mobile.
• All sources flag as mobile but one says "high abuse score": rotate IP. The current CGNAT slot has been abused by previous users.
• All sources clean but the target platform still flags: the problem is your browser fingerprint or behavioral pattern, not the proxy.

Automating the Checks

For teams managing 10+ proxies, manually clicking through six websites per proxy doesn't scale. A minimal Python automation:

import requests

def check_proxy(host, port, user, password):
    proxies = {
        'http':  f'socks5h://{user}:{password}@{host}:{port}',
        'https': f'socks5h://{user}:{password}@{host}:{port}',
    }
    r = requests.get('https://ipwho.is/', proxies=proxies, timeout=15).json()
    return {
        'ip':       r.get('ip'),
        'country':  r.get('country'),
        'org':      r['connection'].get('org'),
        'type':     r['connection'].get('type'),
        'asn':      r['connection'].get('asn'),
        'is_mobile': r['connection'].get('type') == 'mobile',
    }

print(check_proxy('proxy-host', 5000, 'user', 'pass'))

Run this against your full proxy inventory daily — it surfaces silent failures (modem offline, carrier issue, IP type drift) before they affect campaigns.

Testing ProxyGrow Proxies

ProxyGrow's on-site checker at proxygrow.com/#checker runs the IP and WebRTC check automatically. For DNS and reputation tests, use the external tools listed above.

Our mobile proxies use real SIM cards from Ukrainian, Romanian, and Latvian carriers — they pass carrier detection, have clean reputation, and include pOSfp spoofing on Premium plans. The checker output is the same data you'd get from ipwho.is, formatted so you can verify carrier, country and ASN at a glance before completing your purchase.