Both browsers ask for the same five fields, and one wrong answer in the type field makes a perfectly good line report as dead. Here is what to put where.
Open the dashboard, pick the plan, choose a country and press generate. What you get back is one line per
proxy in the form host:port:username:password — for example
gw.pyproxy.com:1111:px12154e319-country-de:BkiXQvBSjkxy. The country sits inside the username, which
is why you generate a new line rather than editing anything by hand.
Copy the line straight out of the dashboard. Retyping it is the second most common cause of a failed check, because the dashes in the username are part of the credential and a single missing one turns into an authentication error rather than a helpful message.
In the profile editor open Proxy and add a new one:
| Field | What to put in it |
|---|---|
| Type | HTTP for rotating residential traffic. SOCKS5 only on static ISP, mobile, datacenter and per-IP lines. |
| Host | The first part of the line, gw.pyproxy.com. |
| Port | The second part — 1111 for residential. 3128 and
8888 answer the same credentials if your network filters 1111. |
| Login | The third part, including the -country-xx tail. |
| Password | The fourth part. |
Press Check proxy. A working residential line answers in one to three seconds and shows the country you asked for.
Under Proxy info choose Proxy type: HTTP, paste host, port, username and password into
their four fields, and use Check proxy there as well. AdsPower additionally lets you paste the whole
line at once in the batch importer; the order it expects is host:port:username:password, which is the
order the dashboard hands out, so no rearranging is needed.
Rotating residential runs on a pool that speaks HTTP CONNECT and nothing else. Set the type to SOCKS5 and the connection is closed during the handshake, in about fifty milliseconds — far too fast to look like a network problem, and indistinguishable in the browser's report from a proxy that no longer exists. The dashboard only offers the protocols a given plan actually serves for the same reason, but the type has to be set again inside the antidetect browser, where nothing of ours can correct it.
You can prove which protocol a line speaks in two commands:
curl -x http://USER:PASS@gw.pyproxy.com:1111 -s -o /dev/null -w "http %{http_code}\n" https://api.ipify.org
curl -x socks5h://USER:PASS@gw.pyproxy.com:1111 -s -o /dev/null -w "socks %{http_code}\n" https://api.ipify.org
On residential the first prints 200 and the second fails. That is expected, not a fault.
Add a session tag to the username and the pool keeps the same exit for up to thirty minutes:
px12154e319-country-de-session-a1b2c3d4. Thirty minutes is what the pool was measured to hold, so treat
it as a ceiling rather than a promise for longer work. For accounts that must keep one address for weeks, use a
static ISP or a per-IP product instead of rotating traffic.
If a plain curl through the gateway fails too, send us that exact command and its output. It turns a
support conversation into a diagnosis.
Change the type to HTTP and press check again. Rotating residential answers HTTP CONNECT and closes a SOCKS5 handshake immediately, and the browser cannot tell that apart from a dead server.
HTTP for rotating residential. SOCKS5 or HTTP for static ISP, mobile and datacenter lines and for per-IP products — those pools answer both.
It can. The browser opens the proxy through whatever route the VPN leaves in place, and some clients capture the whole interface. Test the line with curl outside the browser before blaming the proxy.
Up to 30 minutes with a session tag on residential traffic, which is the measured ceiling of that pool rather than a figure we chose. Without a tag every request rotates.
Yes. The same credentials answer on 1111, 3128 and 8888, so try the other two before assuming an outage.