Why Antidetect Browsers Need Proxies

An antidetect browser is a per-profile identity container. It isolates cookies, storage and cache, and presents a consistent, plausible set of JavaScript and header values to whatever page you load. Multilogin's Mimic, GoLogin's Orbita, Octo's Octium: all Chromium forks doing variations on the same renderer-level job.

A proxy is a network origin. It changes the source address of the TCP connection, and with it the ASN, the subnet, the reverse DNS and the geolocation any lookup service will report.

Neither can do the other's work. That is not a marketing distinction, it is an architectural one:

The word "before" in that second row is the whole article. We covered the buying decision in antidetect browser vs proxies. This page is about what the network half is actually doing once you have both.

Here is the honest split. Every signal a platform can read about a session, and whether the browser can change it:

The first six rows are a hard no, and not because of any vendor's limitations. That is simply where the data lives. A Chromium fork can rewrite what navigator reports because that is a JavaScript object it owns. It cannot rewrite the source address in the IP header, because by the time the packet reaches the network stack the browser is no longer holding the pen.

One row is genuinely shared. The TLS handshake sits between the layers and both halves affect it, which is why TLS fingerprinting trips people who assumed the browser had them covered.

This is the sequencing point most guides skip, and it explains a lot of confused support tickets.

A protected site evaluates you in stages. The connection arrives, TLS is negotiated, headers are parsed, and the edge makes a routing decision. Only if you clear that gate does the HTML come back, and only then does your carefully built JavaScript identity get a chance to execute. When an edge serves a challenge page instead of the app, it decided that with nothing but the IP, the TLS client hello and the request headers. Your antidetect browser's entire value proposition is expressed in code that runs after that decision.

What reputation means in practice

Reputation is not one number. It is a set of independent lookups against the address you connected from:

• ASN classification. Is this address in a range registered to a hosting provider, a consumer ISP or a mobile carrier? The registry data is public and the lookup is cheap.
• Abuse history. Has this address or its neighbours appeared in credential-stuffing, spam or scraping reports recently? Blocklists age out, but slowly.
• Concurrency. How many distinct sessions has this address opened in the last hour, and does that look like a household or a server?
• Consistency. Does the address belong to the same account it belonged to yesterday, or is it new to this account?

The last two are the ones you control with configuration rather than purchase. A clean IP behind eighty simultaneous profiles is a dirty IP by lunchtime.

Buying more IPs is the reflex. Buying more neighbourhoods is the fix.

Correlation engines do not only match exact addresses. They match prefixes, because a prefix is where the cheap signal is. A /24 holds 256 addresses and is almost always one allocation to one customer. If your twenty profiles sit on twenty different addresses inside 203.0.113.0/24, a query on the first three octets returns all twenty in a single row. You bought twenty IPs and got one identity.

The same logic runs one level up. Twenty profiles spread across twenty subnets that all belong to the same hosting company still share an organisation name in every WHOIS lookup.

It extends into time as well, which almost nobody prices in. If all twenty profiles log in within the same nine-minute window every weekday morning, the addresses barely matter. Behavioural co-occurrence is a cheaper join than any network attribute. Stagger the schedules.

Rotating proxies are the default product most people buy, and for account work they are the wrong default. Rotation is right for stateless collection: price checks, SERP sampling, catalogue crawls, ad verification. Every request is independent, so a fresh address per request spreads load and dodges per-IP rate limits.

An antidetect browser profile is the opposite. It is a persistent identity that the platform is deliberately tracking across sessions. Every time the exit address changes mid-session you generate a login-location event, and a profile that appears from a new city three times an hour is a louder signal than any canvas hash you could have leaked.

So the profile wants a sticky session: one token, one exit address, held for the life of the session. On SparkProxy that is port 11002, with the session token carried in the username:

Type:      HTTP
Host:      gateway.sparkproxy.io
Port:      11002
Username:  user-country-us-session-acct42
Password:  your-password

That credential string is doing three jobs at once: authentication, country selection and session pinning. Swap acct42 for a per-profile identifier and each profile holds its own exit. Verify it before you trust it:

# Same session token twice. The exit IP must be identical both times.
curl -x http://user-country-us-session-acct42:PASS@gateway.sparkproxy.io:11002 https://ipinfo.io/json
curl -x http://user-country-us-session-acct42:PASS@gateway.sparkproxy.io:11002 https://ipinfo.io/json

# A different token must give a different exit, or two profiles are sharing an IP.
curl -x http://user-country-us-session-acct43:PASS@gateway.sparkproxy.io:11002 https://ipinfo.io/json

# Port 11000 rotates on every request. Right for scraping, wrong for a logged-in profile.
curl -x http://user-country-us:PASS@gateway.sparkproxy.io:11000 https://ipinfo.io/json

# SOCKS5 on 13000, for browsers whose proxy field prefers it.
curl -x socks5h://user-country-us-session-acct42:PASS@gateway.sparkproxy.io:13000 https://ipinfo.io/json

Because the session token lives in the username, credential formatting matters as much as the host does. How proxy authentication works covers the failure modes, including antidetect browsers that mangle passwords containing reserved URL characters. If every profile runs from one machine with a static address, IP whitelisting takes the credential string out of the browser config entirely, which is one fewer thing to get wrong per profile.

A profile whose IP resolves to Frankfurt and whose JavaScript reports America/Chicago has told the page something no real user could tell it. That single contradiction is worth more to a risk engine than a dozen individually plausible values, because plausible values are cheap and consistent ones are not.

Most antidetect browsers derive timezone, locale and the WebRTC public address from the proxy when you let them. The mismatch usually comes from human sequencing: the profile gets created first, the proxy gets attached second, and the timezone quietly kept the host machine's value. Audit it from inside the profile, with devtools open on any page:

// Run this inside the antidetect profile, not your normal browser.
const geo = await (await fetch('https://ipinfo.io/json')).json();
console.table({
  browserTimeZone: Intl.DateTimeFormat().resolvedOptions().timeZone,
  browserLanguages: navigator.languages.join(','),
  ipAddress: geo.ip,
  ipCountry: geo.country,
  ipRegion: geo.region,
  ipOrg: geo.org
});

Three comparisons, in order of how much they cost you when wrong:

1. browserTimeZone has to be a zone that exists in ipCountry. Not merely the right UTC offset, the right named zone. Europe/Berlin and Europe/Paris share an offset and are different answers.
2. The first entry in browserLanguages should be plausible for that country, and it has to match the Accept-Language header the profile actually sends. Those are set in two different places in most antidetect browsers and they drift apart.
3. ipOrg gives you the ASN and the registered organisation. If it names a hosting company and the profile is meant to look like a household, you have learned something useful before the platform did.

Filling in the browser's proxy field routes the browser's HTTP traffic. It does not route everything, and the gaps are documented in Chromium's own source tree.

WebRTC and UDP

Chromium's networking docs are blunt about the SOCKS5 limitation: "In Chrome SOCKSv5 is only used to proxy TCP-based URL requests. It cannot be used to relay UDP traffic." SparkProxy's SOCKS5 endpoint on port 13000 is TCP-only for the same reason, with no UDP ASSOCIATE, and a provider promising otherwise for browser traffic is describing something Chrome will not use anyway.

The consequence is direct. WebRTC gathers ICE candidates over UDP, on the real interface, outside the tunnel you configured. A page with three lines of RTCPeerConnection code reads your actual public address while every HTTP request politely arrives from the proxy.

The fix belongs to the browser layer. Chromium's WebRTC IP handling policy has a value named disable_non_proxied_udp, which lines up with Mode 3 in RFC 8828, the WebRTC IP Address Handling Requirements published in January 2021. Every competent antidetect browser applies an equivalent per profile and rewrites candidates to the proxy exit. Verify rather than assume: this is the most common gap between a profile that looks configured and one that is.

DNS

Chromium resolves names differently depending on the proxy scheme. From the same document: with SOCKSv4 "name resolution for target hosts is always done client side", while with SOCKSv5 "name resolution is always done proxy side". So socks5:// keeps lookups on the proxy and socks4:// hands every hostname you visit to your local resolver. Use SOCKS5, or socks5h:// in curl, and never SOCKS4 for this work.

HTTP proxies on ports 11000 and 11002 are safe by construction, since CONNECT carries the hostname and the proxy resolves it. The residual risk is side channels: extensions with their own network access, and DNS-over-HTTPS settings at the OS or browser level that bypass the profile's proxy entirely.

Six checks, about four minutes per profile, and they catch nearly everything.

1. The exit address is the proxy's, not yours. Load an IP echo inside the profile. If you recognise the address, stop.
2. Sticky is actually sticky. Same session token, two requests five minutes apart, same address both times.
3. Profiles do not share an exit. Two different tokens must return two different addresses.
4. The ASN is what you expect. Read org from the echo. A residential-looking profile on a hosting ASN is a mismatch you chose.
5. WebRTC shows the proxy only. Any ICE candidate carrying your real public address means the browser's UDP policy is not applied.
6. Timezone, locale and country agree. Run the console snippet above and read all three rows.

Run check 2 across a real interval rather than back to back. Session TTLs are what quietly expires under you, and a token that holds for ninety seconds is not a sticky session in any useful sense.

There is no universally best IP type, only a match between the address and the workload.

Our disclosure, since we sell one half of this stack and only one of those four types: SparkProxy provides datacenter proxies, reached at gateway.sparkproxy.io on port 11000 for rotating HTTP and HTTPS, port 11002 for sticky sessions and port 13000 for SOCKS5, with a 24-hour free trial for measuring exit-IP stability before you commit profiles to it. Datacenter addresses fit the workloads in that first row well and are honestly a poor fit for consumer social accounts, which generally want residential or mobile exits. That is a different product and we do not sell it. Anyone telling you one IP type covers every antidetect use case is selling rather than advising.

In rough order of how often they cause the problem:

• Creating the profile, logging in, then attaching the proxy. The first session is the one a platform remembers hardest. Attach the proxy before the profile ever loads a page. Warming up profiles on your own connection is the same mistake dressed as diligence.
• Buying IP count instead of subnet spread. Fifty addresses in two /24s is two identities with a lot of decoration.
• Leaving the profile on a rotating port. Port 11000 behaviour inside a logged-in session produces a location change per request.
• Reusing one sticky token across several profiles. The token is the identity, so copying a browser config between profiles copies the exit address with it.
• Timezone left on the host value. It survives every other fix because nothing in the normal workflow surfaces it.
• Free or shared proxies during setup. The address arrives with somebody else's history already attached and you inherit all of it.
• Never re-checking a working setup. Session TTLs, provider pool changes and browser updates all move underneath you. Re-run the six checks monthly.

Fixing the proxy layer will not rescue a bad browser choice, and the reverse is just as true. If the network side is right and you are still comparing the browser half, the top 12 antidetect browsers roundup has current pricing and fingerprint-engine detail, and Multilogin vs GoLogin goes deeper on the two most commonly shortlisted options.