Dolphin Anty Mobile Proxy Configuration Guide

Dolphin Anty is built for running many profiles at once, which makes it very good at the thing you should never do: attaching one saved proxy to several profiles because it is one click away.

This page is the configuration that works with a dedicated mobile proxy — field by field, then the parts that actually cost people time. The proxy checker that disagrees with curl, and the profile whose timezone argues with its own exit IP.

The configuration, in one block

Create one profile per proxy, select SOCKS5 in the proxy-type selector, and enter host, port, login and password as four separate values rather than as a URL. Then have timezone, locale and geolocation derive from the proxy address, and set WebRTC to altered. That is the whole setup.

Everything below is why each line reads that way, and what breaks when it does not.

Field by field, and the URL trap

Dolphin gives each proxy discrete inputs for type, host, port, login and password. Treat them as inputs. The classic failure is pasting a full proxy URL into the host field, because clients percent-decode the userinfo portion of a URL before use and the credentials that arrive at the proxy are no longer the ones you were issued.

The damage is silent, and the symptom is an authentication failure with credentials that look perfect on screen. A literal @ in a password ends the username early. A literal : splits the fields at the wrong point. A literal % starts an escape sequence and swallows two characters. That mechanism produces a large share of all 407 Proxy Authentication Required reports across every tool in this category.

Two more traps to clear before anything else:

• Ports are per-protocol. The SOCKS5 port and the HTTP port are different numbers, and pointing one protocol at the other's port produces a bare refusal rather than a helpful message. Connection refused covers what a refusal actually implicates.
• Credentials can be per-protocol too. Some providers issue a single pair valid everywhere; others issue separate pairs for SOCKS5 and HTTP so each can be revoked independently. Ours does the latter on newer proxies. Cross the pairs and the credentials are genuinely valid, just not at the address you sent them to.

Pasting a host:port:login:password string is safe, because it splits on colons into the same discrete fields. It is specifically the URL form that breaks things.

The rotation link, and what to do with it

Dolphin lets you store a change-IP URL alongside the proxy, so rotation lives next to the identity it affects. That is genuinely useful, but the useful part is that it makes rotation deliberate, not that it makes rotation easy. Rotating a logged-in profile on a timer produces exactly the pattern account-security systems were built to detect.

Rotate when an address has actually been burned, not on a schedule. Then do two things immediately: confirm the exit IP really changed, and re-check the profile's timezone and locale in case the new address landed in a different region. A rotation that is accepted but leaves the address unchanged is a common and quiet failure — the IP-not-changing checklist covers why a device can report success without moving.

# before rotating
curl -s -x 'socks5h://USER:PASS@HOST:PORT' https://api.ipify.org ; echo
# trigger the rotation, wait for the device to come back, then repeat
curl -s -x 'socks5h://USER:PASS@HOST:PORT' https://api.ipify.org ; echo

If the two values match, nothing rotated regardless of what any dashboard reported. Dedicated versus rotating covers when rotation is the right tool at all — for account work, sticky with rotation on demand is the configuration that fits.

The proxy-check button is not ground truth

This is the biggest single source of confusion in anti-detect setups. Many of these browsers validate a proxy from their own infrastructure, not from your machine. Their checker answers "can our servers reach and authenticate to this proxy", which is a different question from "does this proxy work for me", and the two answers diverge often enough to matter.

Once that is clear, the failure modes stop being mysterious:

• Their servers are on a different network from yours. If the proxy authenticates by IP allowlist, a server-side check arrives from an address that is not on the list and fails by design.
• Their checker depends on some third-party IP-echo endpoint that can rate-limit or block them, which produces intermittent failures while nothing on your side changed.
• Their checker may classify the proxy's network rather than merely test reachability — a separate problem, with its own section below.

Establish ground truth from the machine you will actually browse from, before changing a single Dolphin setting:

# SOCKS5, hostname resolved at the proxy
curl -s -x 'socks5h://USER:PASS@HOST:PORT' https://api.ipify.org ; echo

# HTTP, credentials passed literally rather than through the URL
curl -sv --proxy http://HOST:PORT --proxy-user 'USER:PASS' \
     https://api.ipify.org

Both return a carrier IP — the proxy and credentials are correct, and a Dolphin failure is about how Dolphin is testing. curl fails the same way — you have a real fault, and the diagnostic checklist isolates the layer. SOCKS5 fails but HTTP works — that is resolution or protocol, covered below.

A curl from your own machine is evidence. An in-app checker is an opinion formed somewhere else.

Why an anti-detect browser refuses a proxy that curl accepts

Some anti-detect browsers do more than test reachability — they classify the network the proxy's front-end address belongs to, and reject addresses in ranges they treat as hosting space. The address being scored is the one clients dial, not the one traffic exits from, so a real phone can sit behind a refused front end.

We hit exactly this. Our proxies were rejected by anti-detect tools while answering curl perfectly from the same machine, at the same moment, with the same credentials. No phone, SIM or exit address changed. Moving customer-facing egress onto a different network provider was enough for the same proxies to validate normally in the same tools.

The lesson generalises beyond us. If curl succeeds and the anti-detect browser refuses the proxy, suspect the provider's front-end network before your own configuration. It is a fair question to put to any provider: have you hit anti-detect browsers rejecting your front-end ranges, and what did you do about it? A provider who has never encountered it either has very few customers using these tools, or has not been told.

Timezone, geolocation and language must agree with the exit IP

This is the mistake that actually loses accounts. A US mobile exit address paired with a browser reporting a European timezone is a contradiction ordinary users do not produce, and it is a louder signal than the address itself. Detection systems score disagreement between values, not the quality of any single one.

Let Dolphin derive timezone, language, locale and geolocation from the proxy IP rather than pinning them by hand. Manual values are a maintenance liability: correct exactly until the exit address changes, and then wrong with nothing to announce it.

Three details people miss:

1. Re-check after every rotation. A new address can land in a different region, and any hand-set timezone silently stops matching.
2. Geolocation permission and geolocation value are separate settings. A profile that hard-blocks location requests is unusual in a measurable way; one that answers with coordinates matching its IP is not.
3. Carrier addresses are frequently mis-geolocated. CGNAT ranges get attributed to an operator registration city rather than where the phone physically is, so a checker showing an unexpected city is usually a database artefact rather than proof of a broken proxy.

WebRTC: altered, not real and not disabled

Set WebRTC to altered. WebRTC can enumerate local and public addresses through a path that does not follow the browser's proxy settings, which is how an otherwise correct profile still hands its real address to any page that asks for it.

Real passes your actual addresses through and defeats the proxy for every site that checks. Disabled removes the leak but manufactures a different anomaly, because ordinary Chrome ships WebRTC enabled and a browser reporting it as absent is unusual in a population where nearly everyone has it. Altered keeps the API present and answers with addresses consistent with the proxy, which is what a normal browser on that connection would report.

The rule that governs the entire profile: do not delete a signal, make it agree with the others.

DNS: let the proxy resolve the hostname

Prefer hostname resolution at the proxy rather than on your own machine. When resolution happens locally, your resolver sees every hostname you visit and the destination gets chosen from your real location — a DNS leak that undoes the point of the proxy while every page still loads normally.

That is the socks5 versus socks5h distinction, and the SOCKS5 versus HTTP comparison covers where each applies. Inside a Chromium-based anti-detect browser you usually get the right behaviour by default: with SOCKS5 the hostname is sent to the proxy, and with an HTTP proxy the hostname travels in the CONNECT line. The leak risk moves to the edges — extensions with their own network handling, WebRTC, and anything you run alongside the profile.

One symptom is worth recognising on sight: a proxy that works with a literal IP in the host field but fails with a hostname, instantly rather than after a timeout. That is a resolver fault on the device rather than a configuration error, and the SOCKS5 hostname page has the specific fix.

One profile, one proxy, and keep the pairing

Pair a profile with a proxy once and leave it paired. Two profiles sharing an exit address are linked on the cheapest identifier any platform has, which cancels out the separation Dolphin exists to provide. It matters more here than elsewhere, because a saved-proxy list plus bulk profile creation makes sharing the default outcome.

Reshuffling proxies between profiles is worse than sharing one. It produces an identity whose network location keeps moving while its behaviour stays constant — the signature of a credential being passed around. Instagram proxies works through how these signals are weighed together at the account level, and the same reasoning applies to every platform that scores logins.

Troubleshooting: symptom, cause, fix

Debug from the symptom rather than from the settings screen. Each row is a different layer failing, and the fixes share nothing, so identifying the row is most of the work. Run curl first every time, because it separates your machine from Dolphin's checker.

If no row fits, the general checklist separates a dead proxy from a working proxy that is being blocked — two different problems that get reported with identical wording.

What each layer can and cannot do

Dolphin Anty owns the fingerprint. The proxy owns the address. Neither owns behaviour, account history, or anything a platform already knows, and no configuration of the two produces undetectability. What a correct setup does is remove contradictions between the layers you control, which is a real improvement and a bounded one.

We are the network layer and nothing above it. We do not build an anti-detect browser and cannot separate fingerprints from the network side, which is why Dolphin is a separate and non-optional purchase for account work. If you are still comparing tools, AdsPower and GoLogin present the same settings under different labels, and every argument on this page transfers unchanged.

What a mobile proxy genuinely fixes: a network identity shared across profiles, a datacenter address that costs nothing to block, and an exit that does not resemble a phone. What it does not touch: action rates no human produces, a fingerprint reused across twenty profiles, and an account that is already flagged. For the underlying mechanics, what a mobile proxy is and how mobile proxies work cover the traffic path end to end.

Frequently asked questions

Should I pick SOCKS5 or HTTP in Dolphin Anty?

SOCKS5 by default. It forwards TCP without parsing your traffic, it sends hostnames to the proxy for resolution, and it avoids the CONNECT-authentication problems that make HTTPS return 407 while plain HTTP works. Use HTTP only if something else in your workflow needs it, and remember the two protocols normally sit on different ports and on some providers use different credentials.

Why does Dolphin Anty's proxy check fail when curl works?

Because the two tests usually run from different places. Anti-detect browsers commonly validate proxies server-side, so the result tells you whether their infrastructure could reach and authenticate to your proxy, not whether your machine can. If curl from your own machine returns a carrier IP, your configuration is correct. Then look at IP allowlisting, at whether the checker is scoring the proxy's network, and only after that at your settings.

What should the change-IP or rotation link be used for?

Deliberate rotation, not scheduled rotation. Storing the rotation link with the profile is convenient because it puts the control next to the identity it affects. What you should avoid is rotating on a timer while logged into an account, because an identity whose network location keeps moving without any change in behaviour is the pattern account-security systems look for.

Which WebRTC mode should a Dolphin Anty profile use?

The altered mode. WebRTC can enumerate addresses through a path that ignores browser proxy settings, so real exposes your actual address to any page that asks. Disabled removes the leak but creates a different anomaly, because ordinary Chrome has WebRTC enabled and a browser reporting it as absent stands out. Altered keeps the API present and answers consistently with the proxy.

Can several Dolphin Anty profiles share one mobile proxy?

Technically yes, and it is the most common way people link profiles they meant to keep apart. Co-location on a single exit address is the cheapest correlation a platform can compute, and it cancels out the fingerprint separation the profiles exist to provide. One profile per proxy, paired at the start and not reshuffled later.

Does Dolphin Anty with a mobile proxy make accounts safe?

No. Dolphin Anty handles the fingerprint layer and a mobile proxy handles the network layer. Behaviour, action rates, account age and prior violations sit outside both, and they are scored independently. A correct setup removes contradictions between the layers you control; nothing available makes traffic unexaminable.