The browser is the worst place to debug a proxy, because it hides the actual error behind a generic page. The fix is to stop guessing and narrow the fault down in a fixed order: every site or one site, browser or proxy, then scheme, port, DNS and everything else.
Before changing a single setting, open three unrelated pages — something plain, something large, something you have never visited. What you learn splits the problem in half.
If every site fails, the proxy connection itself is not working. The browser cannot reach the gateway, cannot authenticate to it, or is speaking the wrong protocol. Everything in the next five sections applies.
If most sites load and one does not, the proxy is fine. That site is blocking the exit address, serving a captcha, or geo-restricting the country you picked. The fix is a new exit address, another country, or a sticky session so the site sees a consistent identity — not a rebuilt proxy configuration.
Note the exact error text too. "ERR_PROXY_CONNECTION_FAILED" or "The proxy server is refusing connections" means the browser never got a usable answer from the gateway. A repeating credentials prompt means it reached the gateway and the gateway asked for a login.
This is the test that separates the browser from the proxy, and it takes ten seconds. Open a terminal and run the same proxy details outside the browser entirely:
curl -v -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip
Two outcomes, two completely different investigations:
If curl times out, add -m 15 so you are not waiting on a long default, and try the plain
HTTP target http://httpbin.org/ip as well. HTTP working while HTTPS hangs points at the
CONNECT tunnel rather than at the proxy being unreachable.
Browser proxy dialogs have separate rows for HTTP, HTTPS/SSL, FTP and SOCKS, and the rows are not interchangeable. Putting an HTTP proxy's host and port into the SOCKS row does not make it a SOCKS proxy; it makes the browser open a SOCKS handshake that the gateway does not understand, and every page fails instantly with a connection error.
This matters specifically with residential traffic, which is HTTP and HTTPS only and does not support SOCKS5. If the SOCKS row is filled in, clear it. Put the gateway in the HTTP proxy row and tick the option that uses the same proxy for all protocols — in Firefox that is "Also use this proxy for HTTPS", in the system dialogs on Windows and macOS it is the "use for all protocols" checkbox.
Two related mistakes in the same dialog:
http://gw.pyproxy.com into the host field. The field wants a bare hostname; the
scheme belongs to the row you chose, and some browsers reject or mangle the whole entry.localhost, 127.0.0.1 in the bypass list is fine, but a stray entry such as
* or a domain you are testing means that traffic never goes near the proxy — which looks
like the proxy not working when it is the browser deliberately going around it.A proxy port is not interchangeable either. gw.pyproxy.com listens on 1111;
a digit out of place gives you a connection refused or a silent timeout, and there is no message telling
you the port was the problem. Check it character by character against your dashboard.
The subtler version is a port that is correct but blocked before it leaves your machine. Corporate networks, school networks, hotel Wi-Fi and some home security suites allow outbound 80 and 443 and drop everything else, and a proxy on a high port is exactly what they drop. The symptom is a timeout rather than a refusal — packets go out and nothing comes back.
Test the path to the port on its own, with no proxy semantics involved:
# macOS / Linux nc -vz gw.pyproxy.com 1111 # Windows PowerShell Test-NetConnection gw.pyproxy.com -Port 1111
If that fails while ordinary browsing works, the block is local. Try the same test from a phone hotspot: if it succeeds there, you have confirmed your network is filtering outbound, and the fix is a firewall rule, a different network, or an endpoint on a port your network permits. Local antivirus and "web shield" modules are a common culprit and can be tested by pausing them for one minute.
With an HTTP proxy the browser is supposed to hand the hostname to the gateway and let the gateway resolve it. That is what makes the proxy's location meaningful. Two things break that arrangement.
First, the gateway hostname itself has to resolve on your machine. If your resolver cannot answer for
gw.pyproxy.com, nothing else can happen. Check it directly:
nslookup gw.pyproxy.com
No answer means a DNS problem, not a proxy problem — a broken resolver, a VPN client that hijacked DNS, or a filtering service that blanks unknown domains.
Second, modern browsers resolve names themselves more often than people expect. DNS-over-HTTPS in Firefox and Chrome sends lookups to a resolver of the browser's choosing, and if that resolver is blocked or slow on your network, pages stall before the proxy is ever involved. A local resolver also means geographic answers computed from your real location rather than the proxy's, which shows up as content in the wrong language even though the address reports correctly. If pages hang on "Resolving host", turn secure DNS off temporarily and retest.
Only one thing can steer a browser's traffic. If a proxy switcher, a VPN extension, an ad blocker with a built-in proxy or a privacy extension is installed, it takes precedence over the setting you typed in the dialog, and the result is either your old configuration still being used or an outright failure.
Chrome will tell you plainly: if an extension controls the setting, the proxy section in settings is greyed out with a note naming the extension. Firefox does not always say so.
The clean test is a fresh profile or a private window with extensions disabled. Configure the proxy there, with nothing else installed, and see whether it loads. If it does, re-enable your extensions one at a time until it breaks again. Leave the winner disabled or configure the proxy inside it instead of in the browser dialog — never both.
Hotel, airport, café and some campus networks put a captive portal in front of the internet. Until you accept the terms on their splash page, every outbound connection is intercepted and redirected. A proxy makes this much worse, because the portal's redirect never gets a chance to appear — your browser is trying to reach a gateway that the network will not let it reach, so you see a proxy error instead of the login page and no way to complete it.
The symptom is distinctive: everything fails through the proxy, and the page you do get looks nothing like the site you asked for. The fix is ordering. Turn the proxy off, open any plain HTTP page to trigger the portal, complete the sign-in, confirm you have real connectivity, and only then turn the proxy back on. The same applies after a laptop wakes from sleep on a network whose portal session has expired.
Corporate networks with TLS inspection behave similarly. They terminate HTTPS at their own appliance, which cannot be done to a connection tunnelled to an external proxy, so the proxy connection is dropped. If you are on a managed machine and everything above checks out, this is the likely answer, and it is not something a setting on your side can fix.
Once pages load again, confirm the traffic is genuinely going through the proxy rather than quietly bypassing it. Load a page that reports the address the request arrived from:
https://httpbin.org/ip
If it shows the proxy's exit address, you are done. If it shows your own address, the browser is going around the proxy — a bypass-list entry, an extension, or a setting that did not save. Do this in the browser itself, not in curl; curl can prove the proxy works, but only the browser can prove the browser is using it.
Two refinements worth knowing. Reload the page a few times on a rotating gateway: a different address each time is normal and is the pool working as designed. And if you need the same address to persist — for a login, a cart, a multi-step form — use a session token in the username, which holds one exit address for about thirty minutes.
Run the same proxy through curl from a terminal. If curl loads a page and the browser does not, the proxy is working and the fault is in the browser's settings, an extension or its cache. If curl fails too, the problem is the proxy details, the port or your network.
Because an HTTP proxy entered in the SOCKS field speaks a different protocol, so the handshake never completes and every page fails. PyProxy residential is HTTP and HTTPS only and does not support SOCKS5, so it must go in the HTTP proxy field with the box that applies it to HTTPS as well.
At the proxy. With an HTTP proxy the browser sends the hostname to the gateway and the gateway resolves it, which is what you want. If a local resolver or DNS-over-HTTPS setting answers first you can get results that do not match your proxy location, or blocked lookups that fail before the proxy is ever used.
Load a page that reports the address the request arrived from, such as httpbin.org/ip. If it shows the proxy's exit address rather than your own, traffic is going through the proxy; if it shows your home address, the browser is bypassing it.