How to check a proxy is working before you log in

A proxy that "works" in the sense that pages load is not the same as a proxy that works in the sense that a login page believes you. Websites that protect accounts do not look for a proxy flag, because there is none. They look for contradictions: an address from a server farm, a clock that disagrees with the address's country, a browser that offers up a second address through WebRTC, a DNS resolver on the other side of the world. One contradiction earns a captcha; several earn a verification step or a lock.

This checklist walks through every signal a strict site compares, in the order that catches the most problems fastest, with the test that shows you each one. It applies equally to HTTP and SOCKS proxies, VPN clients and antidetect browser profiles. Run it before you log in, not after.

The checklist at a glance

#	Signal	What passes	Test
1	Public IP	The proxy's address, not your own	Homepage
2	Network type	Residential or mobile for consumer accounts	IP checker
3	Reputation	No blocklist listings, not a Tor exit	Blacklist check
4	Time zone	Browser zone equals the IP's zone	Anonymity score
5	Language	Browser languages fit the IP's country	Anonymity score
6	WebRTC	No public address other than the proxy's	WebRTC leak test
7	DNS	Resolvers in the proxy's country or network	DNS leak test
8	IPv6	No IPv6, or IPv6 at the proxy	IPv6 test
9	Headers	No Via or X-Forwarded-For	HTTP headers
10	Fingerprint	Every component agrees with the claimed platform	Browser fingerprint

Step 1: confirm the proxy is actually in use

Before anything else, open the homepage inside the browser or profile you will log in from. The address at the top must be the proxy's, and the country must be the one you expect. If you see your own provider, the proxy is not applied to this browser: the settings may be system-wide while the browser uses its own, the profile may have the wrong proxy selected, or the proxy may have failed and the connection fell back to direct. Fix that first; nothing else is worth testing until the address is right.

Note the address, the country and the time zone the page reports. You will compare the next steps against them.

Step 2: classify the address

An address is judged by the network it belongs to. Run it through the IP checker, which classifies the announcing network and returns one of 3 verdicts.

• A residential IP from a consumer provider, or a mobile carrier address, reads as a person. This is what sign-up and login systems expect from a normal user.
• A datacenter IP from a hosting company reads as a server. It is not blocked everywhere, but it is challenged far more often, and on consumer platforms it is the single most expensive signal: it costs 25 points on our score and most strict sites treat it similarly.
• A known VPN provider range or a Tor exit is worse than plain hosting, because the network's purpose is on record.

If the classification does not match what you were promised, look at the ASN lookup for the address: it names the organization and shows how the network is typed. An "ISP proxy" that turns out to be announced by a hosting company will be seen as hosting by every site that classifies by ASN, whatever the seller called it.

Step 3: check the reputation

The same address may have been used by someone else an hour ago. Run the blacklist check to query the public DNS blocklists. One listing on an aggressive list is common for shared and residential addresses and usually harmless for web logins; 2 or more listings, or a listing on a list that tracks proxies and bots, means the address has been reported recently and should be swapped before use. The check also flags Tor exits and hijacked ranges, which fail outright.

Step 4: match the time zone

Your browser reports the operating system's time zone to any script that asks, and a site compares it with the zone of your IP. A timezone mismatch is the most common reason a login from a perfectly good residential proxy still gets challenged, because it proves the browser is not where the address is.

Set the system zone to the IP's zone:

• Windows: Settings > Time & language > Date & time, turn off "Set time zone automatically", choose the zone.
• macOS: System Settings > General > Date & Time, turn off automatic time zone, pick the city.
• Linux: timedatectl set-timezone Region/City.
• Antidetect browsers: use the per-profile time zone option, usually "from IP", and verify it rather than trust it.

Then reload the score page. The zone your browser reports and the zone of the address are shown side by side.

Step 5: match the language

The Accept-Language header and navigator.languages are sent with every request and every script can read them. A browser set to one language visiting from an address in a country where almost nobody speaks it is a language mismatch. It is a lighter signal than the time zone, worth 5 points on our scale, but it adds up with others.

Put the country's main language first in the browser's language list (Chrome: Settings > Languages; Firefox: Settings > General > Language) or in the profile's settings. English-speaking countries and multilingual regions are forgiving; a single-language country with an unrelated browser language is not.

Step 6: close the WebRTC leak

WebRTC lets a web page ask your browser for the addresses it can be reached on, and it does so over UDP straight from the browser, bypassing an HTTP or SOCKS proxy entirely. The result is a WebRTC leak: your real public address, handed to the page with 3 lines of script. Run the WebRTC leak test. The only public address in the table must be the proxy's, or there must be none. A different public address is a fail that outweighs everything else on this list, because it is your real address in plain sight.

The fix depends on the setup: a VPN that tunnels UDP, a profile setting that substitutes the proxy address, or disabling WebRTC in the browser. The dedicated article on WebRTC leaks covers each browser.

Step 7: check where your DNS goes

Loading a page starts with a name lookup. If the proxy forwards the connection but the browser resolves the name itself, the lookup goes to your local resolver, usually your real provider. The site cannot see that lookup, but the test can, and so can anyone measuring where its name server receives queries from. A DNS leak is also an inconsistency: resolvers in one country, address in another. Run the DNS leak test; every resolver listed should sit in the proxy's country or belong to the proxy's network.

For SOCKS5 proxies, the fix is remote DNS (Firefox: network.proxy.socks_remote_dns set to true; antidetect profiles usually have a "DNS through proxy" switch). For VPNs, use the client's DNS or a resolver reached through the tunnel.

Step 8: check IPv6

Most tunnels carry IPv4 only. If your connection also has IPv6, a dual-stack site reaches your real network over it while the IPv4 side shows the proxy. The IPv6 test tells you whether you have a working IPv6 route and where it is located. Pass means no IPv6 at all, or an IPv6 address at the proxy. An IPv6 address in your real country is an IPv6 leak, fixed by a tunnel that handles IPv6 or by disabling IPv6 on the system while you work.

Step 9: look at the headers

A transparent or badly configured proxy adds proxy headers such as Via, X-Forwarded-For or Forwarded, and some of them carry your real address. Open the HTTP headers page: the result should say that no proxy-related headers were sent. If any appear, the proxy itself is announcing its presence and no browser-side setting can hide it; use a different proxy.

Step 10: make the fingerprint consistent

Everything above is about the connection. The last step is the browser, and the rule is the same: no contradictions. A browser fingerprint is the set of properties a script can read, from the user agent and client hints to the graphics renderer, fonts, screen and audio engine, and anti-fraud systems check that they agree with each other.

Open the browser fingerprint page and read the components as a story:

Component	Must agree with
User agent platform	Client hints platform, WebGL renderer (a Windows user agent with an Apple GPU is a contradiction)
Mobile flag	Touch points, screen size, user agent
Fonts	The operating system the user agent claims
Languages	The time zone and the IP's country
Screen resolution	A size that exists on real devices, with sensible window size
Canvas and audio hashes	Stable between 2 runs, unless you intend them to be randomized

A spoofed value that disagrees with another value is worse than no spoofing at all. If you use an antidetect profile, run the page twice: a canvas hash that changes between runs means noise is being added, which some sites flag on its own. The user agent page shows how your string is parsed and whether the client hints that real Chromium browsers always send are present.

The 2-minute routine

Once the setup is right, the daily check is short. Open the anonymity score in the profile you will use. It runs the connection checks on the server, adds the browser-side signals when the page loads, and lists every deduction with a link to the fix. A score of 80 or above with no item marked for review is a connection that tells one consistent story: one address, one country, one time zone, one language, no second route.

Repeat it whenever the proxy changes, after any system or browser update, and when a site starts challenging you for no obvious reason. Rotating proxy pools can hand you a datacenter exit or a listed address at any time, and the only way to know is to look before you log in.