# BitBrowser, AdsPower, GoLogin: Setting Up Anti-Detect Browsers with Mobile Proxies

> Markdown version of [the article](https://simplyproxies.com/blog/anti-detect-browsers-with-mobile-proxies.html), kept in sync with it.
> Published 2 November 2026 by Simply Proxies.

Anti-detect browsers solve half of the multi-account problem. BitBrowser, AdsPower and GoLogin each give every profile its own fingerprint: fonts, canvas, WebGL, screen, timezone, the lot. Run two profiles side by side and the websites you visit see two different "computers".

The other half is the network. Every profile still walks out through your real IP address unless you give it a proxy of its own, and a shared IP links profiles faster than any fingerprint quirk. GoLogin's own documentation puts it plainly: even with different browser profiles, multiple accounts will still get linked by the same IP address, so each profile needs its own network identity ([GoLogin docs](https://gologin.com/docs/proxy/introduction/what-is-a-proxy)).

This guide covers the setup end to end: the one-credential-per-profile pattern, the exact proxy fields in all three tools, which protocol to pick, sticky sessions so each profile keeps one stable UK mobile IP, and how to verify the result. Every command below was run against a live UK mobile proxy while writing this, then run a second time on a re-verification pass.

## The pattern: one proxy credential per profile

The single most useful habit is also the simplest: **generate one proxy credential for each browser profile** and never reuse it across profiles.

Why one each:

- **One credential carries one sticky session.** A sticky session pins the credential to one exit IP. If three profiles share a credential, they share the same exit IP, and the IP-linking problem is back.
- **Independent blast radius.** If one identity gets flagged, its exit IP history dies with that credential. Nothing bleeds into the others.
- **Clean accounting.** When profile 7 burns through data, you can see exactly which credential did it.

In the Simply Proxies dashboard, credentials are generated one at a time under Dashboard, and each one is a plain username plus password. In the examples below they appear as `USER` and `PASS`. Your values come from your own dashboard.

## The fields are the same in every tool

All three browsers ask for the same five things per profile. The proxy side of the setup is therefore identical; only the screens differ.

| Field | Value |
|---|---|
| Protocol | SOCKS5 (or HTTPS, see below) |
| Host | `proxy.simplyproxies.com` |
| Port | `6890` (SOCKS5) or `6889` (HTTPS) |
| Username | dashboard username, plus the suffix grammar below |
| Password | dashboard password |

## BitBrowser

BitBrowser documents the flow under Proxy, Http/Https/Sock5/Ssh ([BitBrowser docs](https://doc.bitbrowser.net/help1/proxy/http-https-sock5-ssh)):

1. Go to **Browsers**, click **Add browser**.
2. Under proxy, pick **Custom proxy method**.
3. Choose the **IP lookup service** (BitBrowser offers IP-API among others; pick IP-API so it matches the verification command later in this article).
4. Select proxy type **socks5** and fill in **Host**, **Port**, **Username**, **Password**.
5. Save and open the profile.

For bulk work, BitBrowser's batch import takes one profile per row with the proxy as `Host:Port:Username:Password` (their docs' example: `11.22.33.44:8888:user:password`), so a spreadsheet of profiles with one credential each imports in one go. This is exactly where the one-credential-per-profile pattern pays off.

## AdsPower

AdsPower's create-a-profile guide documents the proxy step ([AdsPower docs](https://help.adspower.com/docs/creating_browser_profiles)):

1. Click **New profile**.
2. In the **Proxy** section choose **Custom**, then the proxy type **SOCKS5**.
3. Paste the whole string into the Host:Port field in their `IP:port:username:password` format and the fields fill in automatically.
4. Click **Check proxy** to test the connection before saving, then **OK**.

AdsPower also has a **Saved proxies** pool with random assignment, which is convenient for scraping pools but is exactly what you do NOT want for account work: a profile whose IP changes at random looks like a new network every session. For profiles that hold logins, set a fixed custom proxy per profile instead. AdsPower's Chrome-based kernel is called SunBrowser and its Firefox-based one FlowerBrowser; either works with the same proxy fields.

## GoLogin

GoLogin assigns the proxy inside the profile settings: enter the provider's credentials (host, port, login, password) in the proxy section of the profile, and each profile connects through its own network ([GoLogin docs](https://gologin.com/docs/proxy/introduction/what-is-a-proxy)). Two of their setup rules are worth following regardless of which tool you use:

- **The profile OS should match your real OS.** A Windows profile opened on a Mac is a detectable mismatch, and checkers like [iphey.com](https://iphey.com) or [pixelscan.net](https://pixelscan.net) will flag it ([GoLogin's key-concepts page](https://gologin.com/docs/getting-started/introduction/key-concepts-profiles-fingerprints-proxies) calls this out with LinkedIn as the platform that punishes it fastest).
- **Default fingerprint settings are fine.** All three tools generate realistic fingerprints automatically; the IP is what you actually have to manage.

## SOCKS5 or HTTPS?

Simply Proxies exposes both: SOCKS5 on port 6890 and HTTPS on 6889. Two practical notes:

- **SOCKS5 with username and password works inside anti-detect browsers** because they implement their own proxy handling. Be careful reusing that assumption in stock Chromium: plain Chromium does not implement SOCKS5 authentication at all (we verified that in the source and live last month: [Does Your Proxy Leak DNS?](https://simplyproxies.com/blog/does-your-proxy-leak-dns.html)). Inside BitBrowser/AdsPower/GoLogin profiles it is a non-issue; in hand-rolled scripts, use `socks5h://` with curl or a library that supports SOCKS5 auth.
- **The HTTPS proxy speaks TLS to the proxy first**, then CONNECT, so credentials never cross the wire in clear. SOCKS5 authentication (RFC 1929) is cleartext inside the tunnel setup; on a trusted home or office network this is academic, but if that bothers you, use port 6889.

## Sticky sessions: one stable IP per profile

A mobile pool rotates by default, which is what you want for scraping and the opposite of what you want for a profile that holds a login. The sticky suffix pins a credential to one device for a sliding window: `-session-<id>` gives a 2-hour default, and `-session-<id>-<minutes>` selects anything from 5 minutes to 12 hours. It is free, and it works on both ports.

Give each profile its own session id, sized to its usage pattern:

- Marketplaces and social accounts you work daily: a long lease such as `-session-acct7-720` (12 hours).
- Something you touch weekly: a shorter lease like `-session-acct8-60`, accepting a fresh IP next session.

You can also pin the **carrier network** with a token straight after the username: `-ee`, `-o2`, `-vodafone` or `-three` narrows the connection to devices on that UK network (EE, O2, Vodafone, Three). If an account was created and always used on one carrier, keeping it on that carrier is the consistent choice. The grammar is `<username>[-<network>][-session-<id>[-<minutes>]]`, network token first.

Here is the whole thing live, one command per line, real output from this article's test runs. Plain credential, two requests, two different UK mobile exits:

```bash
curl --proxy "socks5h://USER:PASS@proxy.simplyproxies.com:6890" \
  "http://ip-api.com/json/?fields=query,country,mobile,isp"
```

```json
{"country":"United Kingdom","isp":"Hutchison 3G UK Ltd","mobile":true,"query":"92.40.209.196"}
{"country":"United Kingdom","isp":"O2 Online","mobile":true,"query":"82.132.217.236"}
```

Now the same check with a sticky session (username `USER-session-article19-30`), three requests in a row, three identical answers. This is what a profile's traffic should look like:

```json
{"country":"United Kingdom","isp":"Vodafone Limited","mobile":true,"query":"148.252.146.38"}
{"country":"United Kingdom","isp":"Vodafone Limited","mobile":true,"query":"148.252.146.38"}
{"country":"United Kingdom","isp":"Vodafone Limited","mobile":true,"query":"148.252.146.38"}
```

A second profile with its own session id (`USER-session-article19b-30`) lands on a different exit of its own:

```json
{"country":"United Kingdom","isp":"O2 Online","mobile":true,"query":"82.132.216.153"}
```

And the carrier token doing its job (`USER-three`), pinning the exit to Three UK:

```json
{"country":"United Kingdom","isp":"Hutchison 3G UK Ltd","mobile":true,"query":"92.40.209.196"}
```

Two profiles, two carriers, two stable IPs, both reading as `mobile:true` from real UK carriers. That is the target end state.

## Verify your setup before you log anything in

Two checks, one minute:

1. **The exit itself.** From any terminal, with your own values:

```bash
curl --proxy "socks5h://USER:PASS@proxy.simplyproxies.com:6890" \
  "http://ip-api.com/json/?fields=status,country,mobile,isp,query"
```

`mobile` should be `true` and `isp` should name a mobile carrier. If a provider's "mobile" pool returns `mobile:false` with a fixed-line consumer ISP, you now know what you actually bought, and this one-line check tells you before the accounts find out the hard way.

2. **The profile as a whole.** Open the profile in your anti-detect browser and visit [iphey.com](https://iphey.com) or [pixelscan.net](https://pixelscan.net). You want a clean trust verdict: fingerprint consistent, timezone and locale matching the exit IP, no WebRTC leak. If the IP section shows your real address, the proxy is not applied; check the port and protocol first.

## Pitfalls worth knowing before they cost you an account

- **Keep the session id stable per profile.** The sticky id is what holds the IP. Rotate session ids only when you deliberately want a new identity for that profile, not as routine hygiene.
- **Do not point ten profiles at one credential.** One sticky session per credential means one IP shared by ten profiles. The fingerprint work in the browser will not save you from that.
- **Match the locale.** A UK IP with a US-formatted profile timezone looks like exactly what it is. Set the profile timezone and language to match the exit (BitBrowser exposes timezone, Geo and language as fingerprint controls; all three tools generate sensible defaults if you leave them alone).
- **HTTPS tools need the HTTPS port.** If a tool only supports HTTP CONNECT proxies, point it at port 6889, not 6890. The credentials and grammar are identical on both.
- **Budget honestly.** Mobile data is real: every page a profile fetches crosses a real SIM. Providers selling "unlimited mobile proxies" are bounded by the SIM underneath; per-GB pricing makes the cost of each profile predictable instead.
- **The proxy is not a licence.** Automated activity still has to stay inside each platform's terms. A clean IP keeps a legitimate workflow working; it does not make a banned-by-rules workflow unbanned.

## Summary

- One proxy credential per browser profile, always; the credential carries the identity.
- All three tools ask for the same five fields: type, host, port, username, password; SOCKS5 on 6890 or HTTPS on 6889.
- Sticky sessions (`-session-<id>`, 2 hours to 12 hours) give each profile one stable UK mobile IP; carrier tokens (`-ee`, `-o2`, `-vodafone`, `-three`) pin the network for account consistency.
- Verify with the registry-check curl (expect `mobile:true` and a carrier ISP) and a fingerprint checker inside the profile before logging anything in.
- Plain Chromium cannot do SOCKS5 auth; the anti-detect browsers handle it themselves, and the HTTPS port is there when you would rather not think about it.

Last verified 2026-11-02: all commands run live against a UK mobile pool during writing and a second re-verification pass; tool setup flows checked against BitBrowser, AdsPower and GoLogin official documentation the same session.