A simple way to troubleshoot a proxy without changing every setting

A proxy stops working, so the natural reaction is to start changing ports, credentials, browser settings, and anything else that looks suspicious. That usually makes the original problem harder to find.

It helps to think of the connection as four separate parts: your internet connection, the proxy, your app, and the website you’re trying to reach.

Start with your normal connection. Turn the proxy off and load a website. Once that works, turn the proxy back on and check your public IP. Seeing your normal IP again is a strong sign that the app isn’t routing through the proxy, although that result alone isn’t absolute proof.

Next, take the app out of the test with curl:

curl -v --proxy http://HOST:PORT --proxy-user "USERNAME" https://api64.ipify.org 

Curl will ask for the proxy password, so it doesn’t need to appear in the command or your shell history.

For SOCKS5 with DNS handled by the proxy, use:

curl -v --proxy socks5h://HOST:PORT --proxy-user "USERNAME" https://api64.ipify.org 

A successful result confirms that this request reached ipify through the proxy. It doesn’t guarantee that every website will accept the same exit IP, but it tells you that the basic connection works.

The error code can also point you in the right direction:

• 407: The proxy requires authentication. Check for missing or incorrect credentials and an IP allowlist mismatch.
• 401: The requested resource requires valid authentication.
• 403: The responding server understood the request but refused it. The exit IP is one possible cause, but cookies, headers, account state, and location rules can also matter.
• 429: A rate limit was reached. The response source still needs to be checked because the limit may come from the destination or another service in the request path.

The dashboard is worth checking too. Look at the plan status, remaining bandwidth, expiry date, authentication method, protocol, and connection limit.

That last one is easy to overlook. A proxy with a limit of 100 concurrent connections can struggle when a scraper is configured with 200 workers. Workers and live connections aren’t always one-to-one, but a workload that exceeds the limit can cause connections to queue, fail, or time out. More internet speed won’t increase the proxy’s connection allowance.

Finish by testing the same destination directly and through another exit IP. That comparison helps separate a local configuration problem, a problematic exit IP, and a restriction imposed by the destination.

The main thing is to test one layer at a time. It’s much easier than changing everything at once and trying to remember which setting made things better or worse.