Proxy string format in antidetect browsers: ip:port:login:pass or login:pass@ip:port
The same four values — host, port, login and password — are written in a different order by every vendor. The proxy cannot tell “you swapped the fields” from “you typed the wrong password”: both arrive as an auth refusal. Hence the rule that saves an evening: verify the credentials with one command first, then argue with the browser's parser.
Two families of formats, and why both exist
There are exactly two. Positional — values separated by colons, each one meaning whatever its position says: host:port:login:password. URL-style — as in an address bar, credentials before the at sign: login:password@host:port. The first came from plain-text proxy lists, the second from the standard URI form that curl and almost every library understands.
Some vendors accept both, some only one. That is why a string copied from one browser's guide silently fails to parse in another: it is perfectly well-formed, this parser just does not expect it.
What each browser accepts
Below are the formats from the vendors' own documentation, with the field order as written there.
- Dolphin{anty} — three base forms: host:port, host:port:login:password and login:password@host:port. Any of them may carry a scheme prefix: http://, socks5://, socks4://.
- GoLogin — both orderings plus two optional suffixes: a :name label at the end and a change-IP URL in square brackets. Hence the example from its docs: http://192.168.0.1:8000:myproxy:pass[https://change-my-ip.com]:name4
- AdsPower — in a profile it is enough to paste IP:port:username:password into the host field and the remaining fields fill in automatically. Bulk create takes the protocol in a separate proxytype column: noproxy, http, https, socks5, ssh.
- Incogniton — one proxy per line as ip:port:username:password, the same shape in every CSV row. The flow is paste, Check, Add.
- Multilogin — only IP:port:login:password or IP:port. No other form is accepted in the address field.
- Octo Browser — host:port:login:password, and for IPv6 the host goes in square brackets: [host]:port:login:password.
- Linken Sphere — the classic host:port:login:password on bulk import, plus JSON configurations for Shadowsocks.
IPv6: the one case where the positional format is genuinely ambiguous
An IPv6 address is itself made of colons. A colon-delimited positional parser cannot tell where the address ends and the port begins — which is why both vendors that support IPv6 in this field chose square brackets. Octo Browser uses [host]:port:login:password; AdsPower's bulk create uses [Host]:Port:Username:Password, with the worked example [1234:abcd:a11:0:0:0:0:e13]:8000:myproxy:password.
Two distinct cases get conflated here. Brackets are needed when the proxy's own address is an IPv6 literal. If you connect to a gateway by hostname or over IPv4 and its exit is IPv6, no brackets are needed at all — the string pastes normally. Most of the confusion behind “IPv6 doesn't work in antidetect browsers” is these two cases taken for one.
What the documentation does not say
An IPv6 format is documented only by Octo Browser and AdsPower. Dolphin{anty}, GoLogin, Incogniton and Linken Sphere never mention IPv6 in their proxy sections. That is not the same as “it fails”: it means the behaviour is undocumented and has to be tested on your own profile. Multilogin's FAQ states plainly that its addresses are currently mostly IPv4 and that IPv6 support is planned.
Credentials first, parser second
Before cycling through field orders, confirm the login and password themselves work. The check takes one command and fully separates “are the credentials right” from “did the browser understand them”.
# -U passes login and password separately from the address, so the
# field order of a connection string plays no part here at all.
curl -x socks5h://GATEWAY:PORT -U LOGIN:PASSWORD https://example.com -o /dev/null -w '%{http_code}\n'
# Same over the HTTP port:
curl -x http://GATEWAY:PORT -U LOGIN:PASSWORD https://example.com -o /dev/null -w '%{http_code}\n'
# 200 -> credentials are fine, the problem is the string format in the browser.
# 407 -> the problem is the credentials, the format is irrelevant.If curl returns 200 and the browser still complains, the question is settled: the credentials are right and all that is left is picking the accepted form from the list above. If curl returns 407, reordering fields is pointless — the credentials are what needs attention.
How to avoid all of this
The surest way not to argue with a parser is not to send a password at all. With IP authentication the machine's address goes on a whitelist and the proxy recognises the client by the connection itself: the browser fields need only host and port, and a four-field format becomes a two-field one with nothing left to swap.
Both methods are active at once here, so nothing has to be switched: a server runs on the whitelist while profiles on a laptop keep using login and password.
Addresses for profiles
Static datacenter IPv4 — packages from 100 addresses, one per profile. Host, port, login and password are handed over as separate fields; authenticate by login or by IP.
View pricingProxies for this job
Check it with our tools
Read next
- The program will not take a proxy login and password: which clients cannot send them, and what to doChromium has never supported SOCKS5 authentication, Android has no password field, netsh has no parameter. A breakdown by client, a one-command check, and the whitelist route around it.
- HTTP or SOCKS5: which proxy protocol to pick for your softwareWhat the proxy can see in each case, where SOCKS5 genuinely helps, and where there is no difference at all — contrary to common belief.
- Automating proxies over the API: whitelist, purchase and renewal from a scriptA PUT to the whitelist replaces the whole list rather than adding to it — that is how people lock themselves out. A walkthrough of our API: the key and its limits, updating an address from cron, purchase and renewal, error codes.