How to test a proxy in 60 seconds (curl, Python, and the built-in tester)

"The proxy doesn't work" is the most common support message in this industry, and nine times out of ten the proxy is fine. The credentials were pasted with a trailing space, the client used SOCKS on the HTTP port, the target blocked the request for reasons unrelated to the IP. A minute of testing before the real job saves an afternoon of guessing. Here is the minute.

Check 1: does traffic go through it at all?

The quickest test is to ask an IP echo service what address it sees. Take the string from your Nyxon plan page or the Generate page. It looks like USERNAME:PASSWORD@HOST:PORT.

With curl:

curl -x http://USERNAME:[email protected]:8080 https://api.ipify.org

If you get an IP back that is not yours, the proxy works. If you get your own IP, the client ignored the proxy. If you get a 407, the username or password is wrong, and the usual cause is copy-paste whitespace or a shell treating a character in the password specially. Wrap the whole -x value in single quotes.

For SOCKS5, change the scheme and the port to the SOCKS port shown on your plan:

curl -x socks5h://USERNAME:[email protected]:9696 https://api.ipify.org

The h in socks5h matters: it makes the proxy resolve DNS, so the target sees the lookup coming from the exit and not from your machine.

Check 2: is the exit where you asked?

An IP being different from yours is not the same as being in the right place. Ask a geolocation service:

curl -x http://USERNAME-country-de:[email protected]:8080 https://ipinfo.io/json

Look at country, region, city and org. The country must match your targeting token. The org line tells you what kind of network you got: a consumer ISP name means residential, a hosting company means datacenter. If you asked for -city-berlin on the premium pool and got Munich, the city was not available at that moment and the gateway fell back to the country; retry or widen the target.

Check 3: does the session stick?

Rotating and sticky are the two modes that confuse people most. Rotating means every request may get a new exit. Sticky means the same exit for the length of the session. Test both on purpose.

Run the first command three times. With a plain username (no session token) you should see the IP change. Now add a session id:

curl -x http://USERNAME-country-de-session-test123:[email protected]:8080 https://api.ipify.org

Run that three times and the IP should stay the same. Change test123 to anything else and you get a different exit. Add -time-600 to hold it for ten minutes instead of the default. The full syntax is in sticky vs rotating sessions.

Check 4: how fast is it?

Latency through a residential exit is higher than direct, because the request travels to the gateway, out through a home connection, and back. Measure it rather than assume:

curl -x http://USERNAME:[email protected]:8080 -o /dev/null -s -w "connect %{time_connect}s  first byte %{time_starttransfer}s  total %{time_total}s\n" https://example.com

Typical numbers for residential are a few hundred milliseconds to first byte. If a single exit is slow, that is normal for residential; rotate and the next one will be fine. If every exit is slow, test from a different machine before blaming the network, because the bottleneck is often the box running the test.

The built-in tester

If you would rather not touch a terminal, the Generate page in the dashboard has a proxy tester. It is prefilled with the first proxy string it generated for you; paste any string from your plans into it and click Test. It runs a real request through the gateway from our side and reports the exit IP, country, city and organisation, and the round-trip latency. It is the same check as commands one, two and four, without the copy-pasting.

Testing the actual target

An echo service accepting your proxy says nothing about whether the site you care about will. Fetch one real page and check the status code and the body:

curl -x http://USERNAME-country-us:[email protected]:8080 -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Safari/537.36" -s -o page.html -w "%{http_code}\n" https://the-site-you-care-about.com/

A 200 with real content means you are through. A 403 or a captcha page on the first request means the site is checking more than the IP, usually TLS fingerprint or headers, and switching pools will not fix that. A 429 means you are being rate limited, so slow down or rotate faster. Notice the -A flag: never test a protected site with curl's default user agent, because that alone is enough to get blocked and you will blame the proxy.

A Python version of all of the above

import requests, time

PROXY = "http://USERNAME-country-us-session-abc123:[email protected]:8080"
proxies = {"http": PROXY, "https": PROXY}
headers = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Safari/537.36"}

t = time.time()
r = requests.get("https://ipinfo.io/json", proxies=proxies, headers=headers, timeout=20)
print(r.status_code, round(time.time() - t, 2), "s")
print(r.json())   # ip, country, region, city, org

Run it twice. Same session id, same IP. Remove the session token, new IP each time.

When it really is the proxy

If the echo test fails with a connection error rather than an HTTP error, check three things in order: the host and port match what your plan page shows for the product (different pools use different gateways), your plan still has traffic and has not expired (the plan page shows both), and your network allows outbound connections on that port. If all three are fine and it still fails, open the live chat and paste the exact command and error. A human answers, usually within minutes.