One profile, one proxy: the rules that keep accounts apart

The rule, before the reasons

One profile, one proxy, held for the life of the account. Everything below is an argument for that sentence, or an account of what breaks when you deviate from it.

It is worth stating that bluntly because a platform deciding two accounts belong to one operator is not running a single test. It is joining evidence, and the network address is the cheapest join available: no script has to run, nothing is written to disk, and the address is measured before the page is served. A browser fingerprint can be made coherent and a profile directory genuinely separate, and both are undone by two accounts leaving from one IP on the same afternoon. What running several accounts requires is the longer version of that problem.

What follows are the questions people ask after buying their first pool: which kind did I need, does rotation help, why did the account get flagged anyway, and what happens when the proxy dies at eleven at night.

Four kinds, and what each one is for

Proxies are sold under four labels. Each describes where the exit address lives and who it is registered to, and those two facts are most of what a receiving site can cheaply learn about it.

Kind	Where the exit is	Registered to	Typical billing	Right for
Residential	A consumer broadband connection	A consumer ISP	Metered, per gigabyte	Signed-in account work
Datacenter	A server in a hosting facility	A hosting company	Flat, per IP per month	Fetching public pages at volume
ISP / static residential	A server in a hosting facility	A consumer ISP	Flat, per IP per month	Long-lived accounts that need a stable address
Mobile	A mobile carrier's network	A carrier	Metered, most expensive	The few accounts that warrant the cost

The column that does the work is the third. Every routable address block is delegated through a registry and carries a record of who holds it, and every block is announced by an autonomous system — RFC 1930 defines an AS as "a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy", identified by a globally unique number. Both facts are public. A site that wants to know whether an address belongs to a hosting company or a broadband provider needs a lookup, not a model and not your cooperation.

So a datacenter exit is not a secret you can keep, and not a defect either. Fetching public pages at volume is what those addresses are for, and collection work usually wants them. The mistake is signing in from one, because no work inside the browser reaches a fact measured outside it.

Mobile sits at the other end for a structural reason. Carriers place large numbers of subscribers behind carrier-grade NAT, where, as RFC 6888 puts it, "a public IPv4 address would be shared by many subscribers". A platform cannot ban such an address without banning everyone behind it, so it absorbs more scrutiny before anyone acts on it. That tolerance is the product, and it is why mobile is priced the way it is.

ISP proxies are the interesting middle, and the place where honest advice has to stop short of a promise. The registration says consumer ISP; the machine answering is in a facility. Some platforms classify by the registered holder and see an ISP; others keep their own view of which ranges sit in data centres and are not fooled. Which you are dealing with is not something a vendor's product page can tell you, nor this one. It is answered empirically, against the platforms you care about, before an account depends on the answer.

What Argus contributes is measurement rather than opinion. Proxies live in a shared library and are assigned per profile, and every one is health-checked for the egress IP a site will actually see, the country it resolves to, and the latency of the hop. The same check flags an exit sitting on a datacenter network and names the provider behind it — which is how you learn that a pool sold as residential answers from a hosting range, from a table row rather than from a client's account. The proxies page is the buyer's guide.

SOCKS5, HTTP, and the handshake Chromium cannot perform

An HTTP proxy sits at the application layer. It parses your request, forwards it, and can rewrite headers on the way. For TLS traffic it uses CONNECT to open a tunnel it cannot read, but it is still speaking HTTP to you.

SOCKS5 works lower down. RFC 1928 describes it as "conceptually a 'shim-layer' between the application layer and the transport layer": the client asks the proxy to open a connection to a host and port, and after that bytes are relayed without the proxy parsing or rewriting anything. That protocol-agnosticism is the practical difference, and it is why most commercial endpoints are sold as SOCKS5.

Authentication is the part that matters operationally. RFC 1928 defines a method-negotiation step in which the client offers the methods it supports and the server picks one: X'00' for no authentication, X'02' for username and password. That second method is specified separately in RFC 1929, a short subnegotiation where the client sends a username and password and the server answers with a status byte, and "a STATUS field of X'00' indicates success".

Chromium's own SOCKS5 client only speaks the no-authentication variant. A proxy requiring a username and password therefore cannot be used with it at all, which rules out a large share of what providers sell, and every anti-detect tool automating a browser it did not build inherits that limit. Argus ships its own Chromium build and closes it there: a local relay performs the RFC 1929 handshake on the upstream leg while the profile is pointed at a loopback address, so no proxy authentication dialog appears. It is among the browser-side capabilities on how it works, and one of the clearer reasons to ship a browser rather than script someone else's.

Country, timezone, locale, language: four answers to one question

A site can ask where you are in several ways, and it costs nothing to ask all of them and compare the answers.

The address gives it a country by lookup. The browser gives it a clock: Intl.DateTimeFormat().resolvedOptions().timeZone returns an IANA zone name, and per MDN "the default is the runtime's default time zone" when none was specified — no permission prompt, no user interaction, one line of script. resolvedOptions().locale returns the BCP 47 tag actually negotiated. And every HTTP request carries Accept-Language, which MDN describes as indicating "the natural language and locale that the client prefers", with navigator.languages reporting the same preference to script.

Four sources, one question. A session arriving from a São Paulo address while reporting Europe/Warsaw, pl-PL and a Polish language list has contradicted itself before the page finished loading, in a way that is trivially machine-checkable. The principle is the one that governs the rest of the device: a fingerprint is judged as a set, and the question is not whether any single value is unusual but whether the values together describe a machine that could exist. Scrambling fields independently makes it worse, because each random field is another chance for two of them to disagree. That argument in full is on the fingerprints page.

Argus sets the timezone per profile in the renderer, generated as part of the same coherent set as the platform, languages, screen and CPU count, and derived from the location the proxy's own health check measured rather than typed in by hand, so the clock agrees with the exit by construction. What it does not do is spoof the Geolocation API. That one is permission-gated: a site has to prompt, and the answer is to decline, which is what most real sessions do anyway. Nor does Argus synthesize motion or orientation sensor input, because that cannot be done convincingly: an event created from script is marked untrusted in a way a page can read and a script cannot change, so a fabricated sensor stream announces itself. Better to know that now than after building a workflow on it.

Rotation is a collection setting, not an account setting

Rotation means the exit address changes on a schedule: every request, every few minutes, or whenever the provider's pool decides. A sticky session holds one address for a stated period; a dedicated IP holds one indefinitely. Providers sell all three off the same pool, and which one you are on is usually a hostname or a port rather than a different product.

The two jobs want opposite settings, and this is the most expensive confusion in the category.

Collection wants rotation. When you are fetching public pages at volume, spreading the load across many addresses is the point: no single address carries enough traffic to be worth acting on, and losing one costs nothing. Nothing is signed in, so nothing breaks when the address changes mid-run.

A signed-in session wants the opposite. An account whose address changes mid-scroll looks like a hijacked session, because that is precisely what a hijacked session looks like from the platform's side, and the response is a verification cycle at best. Buy sticky sessions or dedicated addresses for account work, and ask the provider how long a sticky session actually holds before it rotates anyway. The advertised figure and the observed one are not always the same number.

In Argus the address is a property of the profile rather than a global setting: assigned once from the library and applied through the profile's own proxy configuration on every launch, not by an extension a page could detect, alongside the profile's own directory and its own saved session. Nothing has to be remembered at launch time because the pairing is stored, which is what makes a list of hundreds of profiles manageable at all.

WebRTC, and why it undoes everything above

A proxy only covers the traffic that goes through it. WebRTC is the classic route around one, and it is worth knowing precisely rather than as folklore.

WebRTC establishes peer-to-peer connections, and to do that it has to discover how each peer can be reached. That discovery is ICE candidate gathering, and MDN sets out the kinds of candidate it produces. A host candidate is one whose address "is the actual, direct IP address of the remote peer", taken from the machine's own interfaces. A server-reflexive candidate comes from asking a STUN server what public address the traffic appears to arrive from. A relay candidate goes through TURN and exposes the relay's address instead.

The problem is that a page does not need to place a call to see any of this. Candidates are surfaced to script through the icecandidate event, which fires once a local description has been set — a few lines of JavaScript, with candidates arriving whether or not anything is on the other end. A browser dutifully sending every HTTP request through a proxy can hand over its real public address, and historically its local ones too, through this path.

The IETF addressed this directly. RFC 8828 defines four modes for IP address handling, from Mode 1, in which "WebRTC MUST use all network interfaces to attempt communication", down to Mode 4, which forces WebRTC traffic through the application's proxy and disables non-proxied UDP. The RFC is explicit that the restrictive modes cost media quality, which is why Mode 2 rather than Mode 4 is the recommended default for an ordinary browser. Chromium exposes the four as policy values — default, default_public_and_private_interfaces, default_public_interface_only and disable_non_proxied_udp — in webrtc_ip_handling_policy.cc. Browsers separately conceal local addresses behind randomly generated mDNS hostnames, an approach specified in an IETF draft that expired without becoming an RFC. The W3C's specification notes that an implementation "can still use its own candidate filtering policy in order to limit the IP addresses exposed to the application".

Two things follow. First, the right default for a general-purpose browser and the right default for a profile that must never reveal its host are different, and the trade the RFC describes — media quality against exposure — is one you are glad to lose. Argus takes the most restrictive, disable_non_proxied_udp, on every profile: enforced as browser policy beneath the JavaScript layer where a page cannot switch it off, set for the profile rather than offered as a toggle somebody forgets. Assigning a proxy to a profile that was still reporting its real address upgrades it automatically. That is what matters at scale, because a control which has to be remembered forty times will be remembered thirty-nine.

Second, the operational point: a WebRTC leak fails silently. Nothing about the session looks wrong, and you find out when two accounts that should never have met get actioned together. By then the linkage is made, and it is not evidence you can argue with.

What happens when the proxy dies

A proxy fails. The term ran out, the provider had an outage, the credentials were rotated, the host stopped resolving. Somewhere a browser is about to launch a profile that is supposed to arrive from Lisbon. This is the scenario the rest of the post exists for.

There are two possible behaviours and only one is defensible. A tool that fails open falls back to the direct connection and opens the session anyway. From the operator's side nothing happened: the profile launched, the page loaded. From the platform's side, an account that has arrived from Lisbon for eight months just signed in from your office. Do that through a provider outage across a working set of profiles and you have stamped one real address across every account that launched in that window — the exact evidence needed to conclude they are one operation, produced by the tool bought to prevent it.

Argus fails closed. A proxy that fails its check blocks the launch: the session does not open. That is a worse afternoon and a much better outcome, and it is the first thing worth checking in any tool in this category.

Two related behaviours follow the same logic. Reachability is not acceptance: a proxy can connect, resolve to the right country and still be refused by the sites you actually use, because the services a connection check queries are the ones that never block anyone. So a slower background sweep loads real destination sites through each proxy, and launching behind one that a required site refused asks you to confirm first, naming what refused it. And because a term ends on a date nothing in the network can tell you, the expiry date is a field you record when you buy.

What none of this fixes

Being specific about the boundary is more useful than another paragraph of reassurance.

Argus does not alter the TLS fingerprint, and does not claim to. A ClientHello is sent before any HTTP request exists, and hashing its structure — versions, cipher suites, extensions, curves, and the order they are listed in — identifies the software connecting. Nothing in the fork touches it, and that is the intended position rather than a gap: Argus ships a real Chromium build, so the handshake is a genuine Chromium handshake matching the browser it claims to be. A script using a generic HTTP library while sending a Chrome user-agent has a TLS fingerprint no Chrome has ever produced, and that mismatch is decisive. Being a real browser is the answer, not a workaround.

Behaviour is not covered either. Nothing about a browser stops two accounts posting the same thing at the same minute every day. Three of the four things a platform joins on are separable by software. The fourth is yours.

Two practical limits, plainly: the builds are macOS on Apple Silicon and Windows x64, with no Linux and no Intel Mac; and the automation API is a local HTTP bridge on your own machine rather than a hosted service, which is deliberate but does mean there is nothing to call from a server you do not own.

The short version

Buy the kind that matches the job, not the one that is cheapest per gigabyte. Sticky for accounts, rotating for collection. Make the country, the clock, the locale and the language agree, and generate them together rather than editing them into agreement. Assume WebRTC is trying to give you away, and check that something stops it below the JavaScript layer. Then, before anything else, find out what your tooling does when a proxy fails, because that answer is worth more than every other setting combined.

For the mechanics rather than the rules, how proxies work in Argus follows one request from the profile row to the egress IP, and the recipes are the same material as procedures. For storefronts across several countries, the e-commerce walkthrough carries the marketplace caveats.