Pairing Proxies with Profiles

A client's account has signed in from the same Dallas address every weekday for a year. One morning it appears from Frankfurt, and ten minutes later from Madrid. The fingerprint has not changed at all, and the platform still asks for a verification code.

One identity, one IP

The rule is short. Each profile or cloud phone gets its own proxy, and keeps it. Two accounts never share an address, and one account does not hop between addresses.

Both halves matter. Sharing an IP between two profiles rebuilds the layer-one link that the profiles were meant to remove. Swapping a profile's IP every few days makes a steady account look like a traveler with no fixed home.

The simplest way to keep the rule is to label the proxy with the profile's name. The proxy for acme-ig-us-01 is called acme-ig-us-01-isp and is used nowhere else. Dedicated proxies, which are assigned to a single customer, make this easy to enforce.

Static ISP, residential or mobile

The Proxy Playbook explains how each proxy type works. For long-lived, logged-in accounts the question is narrower: which type behaves most like one real customer's connection over months?

Static ISP addresses are the usual choice for desktop accounts. They are hosted in data centers but registered to consumer internet providers. The account sees the same address every day, as a home or office customer would. They are sold per IP, and the ISP proxies page lists providers.

Mobile addresses suit cloud phones and app-first accounts. Carriers place many subscribers behind each public address, and a phone's address shifts as it moves. An account on a sticky mobile session in one country and carrier matches how phones really behave.

Residential addresses come from household connections that can drop offline at any time. A sticky session holds one for a while, then hands over another. That is acceptable when the replacement stays in the same city and provider. It is less tidy than a static address.

Datacenter addresses are not useless. They are a sound, cheap choice for QA on public pages where nothing is logged in. Live pricing for every type is on the ProxyLook pricing page.

Sticky sessions and the cost of rotation

Rotation was built for scraping. Each request leaves from a new address so that no single address draws attention. For a logged-in account it does the opposite.

One session cookie arriving from five cities in a minute is a familiar sight to a security system. It is what a stolen session looks like. The likely results are a forced logout, a verification challenge or a temporary lock. None of them is a ban, but each one costs time and adds a mark to the account's history.

A sticky session asks the provider to hold one address for a set period. Providers usually set this through the proxy username, in a form like USERNAME-country-us-session-a1b2c3. The exact syntax comes from each provider's documentation.

Location, timezone and language must agree

A proxy that exits in Dallas sets expectations. The profile's clock should read America/Chicago. Its language should be en-US. On a cloud phone, the GPS position should sit in or near Dallas. A Dallas address with a Berlin clock and a German language list contradicts itself.

Many antidetect browsers can fill in timezone, language and location from the proxy's address when the profile is created. The option is worth using, and the result is worth checking once by eye.

QA and ad verification teams apply the same rule in code. The script below opens a page as a visitor in Dallas would see it. The proxy, locale and timezone are set together so the three agree.

from playwright.sync_api import sync_playwright

PROXY = {
    "server": "http://gate.example-proxy.com:7000",
    "username": "USERNAME-country-us-session-a1b2c3",
    "password": "PASSWORD",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY)
    context = browser.new_context(
        locale="en-US",
        timezone_id="America/Chicago",
    )
    page = context.new_page()
    page.goto("https://example.com", timeout=30000)
    page.screenshot(path="dallas-view.png")
    browser.close()

The username format is illustrative. A plain script like this suits checks on public pages. It is not a substitute for a full browser profile on a client's logged-in account.

Checking for leaks

A leak is any path by which the real connection shows through the proxy. Two are common, and both can be checked before an account is ever opened.

WebRTC. Browsers use WebRTC for voice and video calls. To set up a call, it can reveal the device's real IP address to a page, bypassing the proxy. Antidetect browsers have a WebRTC setting per profile. The WebRTC leak test, opened inside the profile, should show the proxy's address or nothing. It should never show the office address.

DNS. Before loading a site, a browser looks up its name. If that lookup goes to the office internet provider while the traffic exits in Dallas, the two do not match. The fix is configuration. With an HTTP proxy, the proxy resolves names itself. With SOCKS5, the option that sends DNS through the proxy should be switched on.

The What Is My IP tool confirms the basics from inside the profile: public address, location, provider and ASN. If any of those show the office, the proxy is not applied.

Setting up one profile end to end

The table gives a starting point for the proxy. The steps then take one account from an empty record to a working profile.

With the proxy type chosen, the setup follows the same order every time.

1. Write the record first. Note the client, platform, profile name and intended location before creating anything.
2. Assign one proxy. Label it with the profile name and confirm no other profile uses it.
3. Create the profile. Pick an operating system and a current engine version, then save the fingerprint.
4. Enter the proxy. Set timezone, language and location to follow the proxy's address.
5. Run the checks. Inside the profile, open What Is My IP and the WebRTC leak test.
6. Sign in once. Complete any verification with the client, who holds the codes.
7. Close and log. Record the date, the exit address and the person responsible.

A matched proxy removes one avoidable link between accounts. It does not change what a platform allows. Multi-accounting can breach terms of service, and the operator carries that risk.