Dolphin Anty proxy format
Last checked 2026-09-10
dolphin anty proxy format
'dolphin anty proxy format' shows up as its own completion, separate from any wording about an error or a failed connection. That is worth taking at face value: some share of the people searching for it are not stuck on a broken proxy at all, they are trying to write the string correctly the first time.
Dolphin Anty documents three input shapes for the same underlying values - host and port on their own, host:port:login:password as one four-field colon-separated string with the host first, and login:password@host:port with the credential pair moved to the front instead. Any of the three can also take a protocol prefix in front of it, such as http://, socks4:// or socks5://, which is how the proxy type itself gets communicated.
The risk is not any one of those three shapes in isolation, it is mixing them: a string built for host:port:login:password pasted into a field that expects login:password@host:port reorders which piece gets read as the host, and nothing in a plain text field stops that from being accepted and simply pointing at the wrong thing.
Everything below runs outside Dolphin Anty. Replace USER, PASS, HOST and PORT with your own values, and keep the single quotes - an ampersand or a hash in a generated password will otherwise be eaten by your shell.
Five-minute checklist
1. Verify host and port alone, the simplest of the three formats
host:port with no credentials is the first format Dolphin Anty documents. If this fails, the host or the port is wrong on its own, before login and password enter the picture at all.
curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'http://HOST:PORT' https://example.com 2. Add login and password as the second format, host:port:login:password, expects them
curl does not parse a raw four-colon string directly, so this command carries the same four values - host, port, login, password - through curl's own user:pass@host:port syntax instead. A failure here means one of the four values is wrong, independent of which order Dolphin Anty wants them written in.
curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'http://USER:PASS@HOST:PORT' https://example.com 3. Confirm the third format, login:password@host:port, behaves the same with no protocol prefix
This is Dolphin Anty's third documented format, written exactly as curl's own scheme-less --proxy syntax. curl's manpage says a value with no protocol prefix is treated the same as an http:// proxy, so this command and the previous one should return the same code; a difference here points at the string itself, not the network.
curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'USER:PASS@HOST:PORT' https://example.com 4. Check whether only HTTPS traffic is blocked once the string is confirmed correct
A correctly assembled string can still fail specifically on HTTPS if the upstream refuses the CONNECT method. Plain HTTP succeeding here while the earlier HTTPS checks failed narrows the fault to CONNECT, not to anything left in the proxy string.
curl -sS -o /dev/null -w 'http_code=%{http_code}\n' --max-time 15 --proxy 'http://USER:PASS@HOST:PORT' http://example.com 5. Confirm the exit IP matches the proxy you meant to reassemble
A string that parses correctly can still point at the wrong proxy if a field was swapped with a value from a different one. Compare this IP against the provider dashboard before assuming the format itself is still at fault.
curl -sS --max-time 15 --proxy 'http://USER:PASS@HOST:PORT' https://api.ipify.org 6. Read the handshake to see which layer stops
Past the format questions above, the verbose trace is what separates a network-level failure from a permission failure from a certificate failure once every field has already been checked.
curl -sS -v --max-time 15 --proxy 'http://USER:PASS@HOST:PORT' https://example.com 2>&1 | head -n 25