You have configured your proxy, connected it to your anti-detect browser, and everything appears to be running. But how do you know it is actually working — and not silently leaking your real identity? Understanding the detection methods websites use is the first step to building a truly reliable setup.
Most proxy failures are invisible. The connection works, pages load, but your real IP leaks through WebRTC. Or your timezone says Singapore while your IP says Germany. Or the proxy IP is already flagged in every reputation database on the internet. These mismatches do not cause errors you can see — they cause account bans you cannot explain.
This checklist covers every verification step you should run before going live with any proxy setup. It takes about 10 minutes and can save you from losing accounts, wasting proxy credits, or burning through warming efforts that were doomed from the start.
Quick Pre-Launch Check (5 Minutes)
If you are in a rush, run these five checks at minimum. They catch the most common and most damaging issues.
- Verify your visible IP matches the proxy location
- Confirm no WebRTC leak is exposing your real IP
- Check that DNS requests route through the proxy (no DNS leak)
- Verify timezone and language match the proxy geo
- Run a quick detection scan (BrowserScan or Pixelscan)
If any of these fail, stop. Do not proceed with live operations until the issue is resolved. The full checklist below explains each check in detail and covers additional verification steps.
The Full Checklist
Check 1: Verify Your IP Address
What you are testing: That the IP address visible to websites is the proxy IP, not your real IP.
How to test: Open your configured browser profile and visit one of these tools: ipinfo.io, whatismyipaddress.com, or ifconfig.me. The displayed IP should match the proxy IP your provider assigned to you.
What to look for: The IP address should be different from your real IP. The country, city, and ISP should match what your proxy provider claims. If you are using a Singapore mobile proxy, the ISP should show a Singapore mobile carrier (Singtel, StarHub, M1, or their subsidiary names) — not a datacenter provider.
If it fails: Your proxy is not connected correctly. Check your proxy credentials (host, port, username, password), verify the protocol (HTTP vs SOCKS5 — using the wrong one is a common mistake), and confirm your anti-detect browser profile has the proxy assigned (not just the browser-level settings). For detailed setup guidance, see our proxy setup guide for multi-account users.
Check 2: WebRTC Leak Test
What you are testing: That your real IP is not being exposed through WebRTC, a browser protocol that can bypass proxy settings and reveal your actual network interfaces.
How to test: Visit browserleaks.com/webrtc with your proxied browser profile. Check the “Public IP Address” and “Local IP Address” fields.
For more details, see our guide on how to detect DNS, WebRTC, and proxy leaks.
What to look for: The public IP should show your proxy IP only. If you see your real IP address anywhere on the page — in the public IP field, the local IP field, or the ICE candidates — you have a WebRTC leak.
If it fails: Disable WebRTC in your anti-detect browser profile. In GoLogin, this is under “WebRTC” in the fingerprint settings — set it to “Altered” or “Disabled.” In AdsPower, find WebRTC under the proxy/fingerprint configuration. In Multilogin, the Mimic and Stealthfox engines handle this differently — check the profile’s network settings. For more details on proper anti-detect browser setup with proxies, see our anti-detect browser proxy workflow guide. Some browser extensions like WebRTC Control can also block these leaks.
Check 3: DNS Leak Test
What you are testing: That your DNS queries (the requests that translate domain names to IP addresses) are routed through the proxy, not through your local ISP.
How to test: Visit dnsleaktest.com and run the extended test. This sends multiple DNS requests and reports which DNS servers handled them.
What to look for: The DNS servers shown should belong to the proxy provider’s network or a neutral DNS service in the proxy’s region. If you see your local ISP’s DNS servers (your home internet provider), your DNS is leaking.
If it fails: Enable DNS-over-proxy in your anti-detect browser settings. If using SOCKS5, make sure “Proxy DNS” or “Remote DNS” is enabled — SOCKS5 supports proxying DNS, but it is often disabled by default. For HTTP proxies, DNS typically routes through the proxy automatically, so a DNS leak usually indicates the proxy connection itself is not working correctly.
Check 4: Timezone and Language Match
What you are testing: That your browser’s timezone, locale, and language settings are consistent with your proxy’s geographic location. Platforms use these as correlation signals — an IP from Singapore with a timezone set to US Eastern is an obvious mismatch.
How to test: Visit browserleaks.com/javascript and check the timezone, language, and locale fields. Compare them to where your proxy IP claims to be.
What to look for: If your proxy IP is in Singapore, the timezone should be Asia/Singapore (UTC+8), the primary language should include English (en-SG or en), and the locale should be consistent. Any mismatch between the IP location and these browser-reported values is a detection signal.
If it fails: Adjust the timezone and language settings in your anti-detect browser profile to match your proxy location. Most anti-detect browsers let you set these per profile. Do not rely on system-level timezone settings — they apply globally and will conflict when you run multiple profiles with different proxy locations.
Check 5: Browser Fingerprint Consistency
What you are testing: That your browser fingerprint (the combination of hardware, software, and configuration signals that websites use to identify you) is consistent and does not contain obvious anomalies.
How to test: Visit BrowserScan.net or Pixelscan.net with your proxied profile. These tools analyze dozens of fingerprint signals and flag inconsistencies.
What to look for: A green or passing score on the overall check. Pay special attention to: Canvas fingerprint consistency, WebGL renderer (should match a real device, not a VM), screen resolution (should be a common resolution for the claimed device type), and platform consistency (the user agent, navigator.platform, and other signals should all agree on the same OS and device).
If it fails: Review your anti-detect browser fingerprint settings. Common issues include: a user agent claiming Windows but a Canvas hash from macOS, a screen resolution that does not exist on real devices, or a WebGL renderer string from a virtual GPU. Most anti-detect browsers generate realistic fingerprints by default, but custom overrides can introduce inconsistencies.
Check 6: IP Reputation Check
What you are testing: Whether the proxy IP address is already flagged in reputation databases as a known proxy, VPN, spam source, or abusive IP.
How to test: Check the IP at IPQualityScore.com/free-ip-lookup-proxy-vpn-test, AbuseIPDB.com, or Scamalytics.com. Enter the proxy IP and review the risk scores.
What to look for: A low fraud score and no flags for “proxy,” “VPN,” or “bot” traffic. For mobile proxies, some detection is normal (mobile carrier IPs are sometimes flagged because they are shared via CGNAT), but a very high risk score suggests the IP has been heavily abused.
If it fails: This is a proxy quality issue, not a configuration issue. If the IP is heavily flagged, request a different IP from your provider or rotate to a new one. Consistently flagged IPs suggest the provider’s pool is overused or includes recycled datacenter IPs marketed as mobile.
Check 7: Speed and Latency Test
What you are testing: That the proxy connection is fast enough for your use case. Extremely slow proxies cause timeouts, incomplete page loads, and behavioral signals (platforms notice when page interactions are unusually slow).
How to test: Visit fast.com or speedtest.net through your proxied browser, or time a set of requests using a simple script. Note both the download speed and the latency (ping time).
What to look for: For browsing and account management: under 3 seconds to load a typical page. For scraping: response times under 5 seconds per request. Latency under 500ms for interactive use, under 1000ms for automated tasks. Mobile proxies are inherently slower than datacenter proxies, but a Singapore mobile proxy connecting to Singapore-hosted sites should have latency under 200ms.
If it fails: Try a different proxy IP or server. If the entire provider is slow, it may indicate overloaded infrastructure, poor routing, or a proxy type mismatch (e.g., routing through multiple hops). For time-sensitive operations like social media management, consider using sticky sessions to avoid the latency hit of establishing new connections.
Check 8: Session Persistence Test (Sticky Sessions)
What you are testing: That sticky session proxies actually maintain the same IP for the claimed duration.
How to test: Start a sticky session and check your IP at ipinfo.io. Wait 5 minutes and check again. Repeat at 15-minute and 30-minute intervals (or whatever your session duration is). The IP should remain the same throughout.
What to look for: The same IP address across all checks within the session window. If the IP changes mid-session, your sticky session is not working correctly — and any platform that tracks IP consistency across a login session will notice.
If it fails: Verify your sticky session configuration. Common mistakes include: using a rotating endpoint instead of the sticky endpoint (providers often have different hostnames or ports for each), not including the session ID parameter in the proxy URL, or exceeding the maximum session duration (after which rotation is forced). Check your provider’s documentation for the correct sticky session format.
Check 9: Multi-Profile Isolation Test
What you are testing: That different browser profiles are actually using different proxy IPs — not accidentally sharing the same connection.
How to test: Open two or more browser profiles simultaneously, each configured with a different proxy. In each profile, visit ipinfo.io and record the IP address.
What to look for: Each profile should show a different IP address. If two profiles show the same IP, your proxy assignment is broken — either the profiles are sharing a connection, or your proxy provider is assigning the same IP to multiple sessions.
If it fails: This is critical for multi-account operations. Check that each anti-detect browser profile has its own proxy configuration (not a shared global proxy). Verify that your proxy provider supports concurrent sessions — some providers share IPs across customers, which means two of your profiles might coincidentally receive the same IP. If isolation is essential (it usually is), use a provider that guarantees dedicated IPs per session. For comprehensive guidance on multi-account proxy infrastructure, see our multi-account proxy guide.
After You Pass All 9 Checks
Once your setup passes every check, document the working configuration. Save the proxy credentials, browser profile settings, fingerprint parameters, and test results. If something breaks later, you will need this baseline to identify what changed.
Re-run this checklist whenever you change proxy providers, update your anti-detect browser, modify fingerprint settings, or notice unexpected account issues. Proxy infrastructure is not “set and forget” — detection systems evolve, proxy pools change, and configurations drift over time.
For the detailed methodology behind how we benchmark and compare proxy providers, see How We Test Proxies — Our Methodology.
Frequently Asked Questions
How often should I run these checks?
Run the full checklist when you first set up a new proxy or browser profile. After that, run a quick check (checks 1, 2, and 5) weekly or whenever you notice unusual behavior like unexpected CAPTCHAs or account warnings.
Can I automate these checks?
Yes. You can script the IP, DNS, and latency checks with curl or a simple Python script. Fingerprint checks (BrowserScan, Pixelscan) are harder to automate but can be done with browser automation tools like Playwright or Puppeteer.
My proxy passes all checks but I still get banned. Why?
The proxy is only one layer of your setup. Account bans can also result from behavioral signals (acting too fast, too predictably, or at unusual hours), cookie/history issues, device fingerprint inconsistencies not caught by Pixelscan, or the account itself being flagged before you started using it. See our comprehensive guide on why accounts get banned even when using proxies for the full picture.
Do I need to run all 9 checks for every profile?
For your first few profiles, yes — run all 9. Once you have confirmed your setup process is reliable, you can use the quick 5-check version for new profiles and save the full checklist for troubleshooting.
Which check catches the most issues?
WebRTC leaks (Check 2) and timezone mismatches (Check 4) are the most commonly missed. Many operators verify their IP but forget to check for leaks or geo-consistency — and those are exactly the signals that sophisticated platforms use for detection.