“Connection failed” is what every client reports for a dozen different causes. Checking them in the right order turns an afternoon of guessing into a few minutes.
Start here, because it is the most common cause and the least obvious. A client set to SOCKS5 against an HTTP-only gateway reports a failure indistinguishable from a dead server. Rotating residential traffic on PyProxy is HTTP(S) only — SOCKS5 lives on the ISP, mobile and datacentre pools and on the per-IP products. If your line came from a residential plan and your tool is set to SOCKS5, that alone explains the failure.
Test the protocol directly rather than trusting the application:
curl -x http://USER:PASS@HOST:PORT -s -o /dev/null -w "http %{http_code}\n" https://api.ipify.org
curl -x socks5h://USER:PASS@HOST:PORT -s -o /dev/null -w "socks %{http_code}\n" https://api.ipify.org
If the first line answers 200 and the second does not, the pool is HTTP and your client is wrong.
Office networks, some mobile carriers and hotel Wi-Fi drop unusual outbound ports. From your side the proxy looks dead; from ours it is answering everyone else.
nc -vz HOST PORT # or: Test-NetConnection HOST -Port PORT
If that refuses to connect, try an alternative port for the same gateway before assuming an outage. PyProxy answers on 1111, 3128 and 8888 with identical credentials for exactly this reason.
Rotation and country targeting are usually encoded in the username, and a stray character breaks authentication rather than producing a helpful message. Copy the line from the dashboard rather than retyping it, and check that your tool is not URL-encoding the dashes or truncating a long password.
With socks5:// your client resolves the hostname locally; with socks5h://
the proxy resolves it. When a site is blocked or poisoned on your network, the first form fails while
the second works. If you are chasing failures that only affect certain domains, this is usually
it.
By this point you have proved the protocol, the port, the credentials and the resolver. If a plain curl through the gateway still fails, collect that exact command and its output and send it to support — it is the difference between a diagnosis and a conversation.
Usually because one of them is doing SOCKS5 with remote DNS and the other is resolving locally, or one is quietly falling back to HTTP. Test both forms with curl to see which.
On PyProxy, no — rotating residential is HTTP(S) only, and that is part of why it is the cheapest traffic here. SOCKS5 comes with the ISP, mobile and datacentre pools and the per-IP products.
Check the port first. Networks change filtering rules without telling anyone, and the same credentials on an alternative port often work immediately.
With socks5:// your machine resolves the hostname; with socks5h:// the proxy does. The second form is what you want when the target domain is filtered on your own network.