Verifying the proxy actually took effect

"The request came back" and "the proxy did what I asked" are two different claims. Run all of these once before you integrate.

1. The exit IP really changed

The baseline check: the IP you get direct and the IP you get through the proxy should differ.

echo "direct: $(curl -s https://api.ipify.org)"
echo "proxy:  $(curl -s -x 'http://USERNAME-country-US:PASSWORD@GATEWAY_HOST:58971' https://api.ipify.org)"

Identical values mean the proxy was never used — usually a malformed -x argument, or a NO_PROXY setting in the client that excludes the target domain.

2. The location matches the country you asked for

A changed IP doesn't prove it landed in the right country. Cross-check with an endpoint that reports attribution:

curl -s -x 'http://USERNAME-country-DE:PASSWORD@GATEWAY_HOST:58971' \
  https://ipinfo.io/json

Compare the country field to what you requested. If it doesn't match, check the syntax first: country must be two uppercase letters, and de is rejected rather than normalised to DE.

3. The sticky session really sticks

Fire several requests with the same session value; the exit IP should not move.

for i in $(seq 1 5); do
  curl -s -x 'http://USERNAME-country-US-session-stick01-time-10:PASSWORD@GATEWAY_HOST:58971' \
    https://api.ipify.org
  echo
done

All five lines should print the same IP. Change the session value and run again — you should get a different one.

If the IP moves mid-session, the likely causes are: time expired, the route rotated its own exit, or your session values differ in case (session is case-sensitive, so Job1 and job1 are two separate sessions).

4. Rotation really rotates

Without session, every new connection goes through route selection independently. Each curl invocation is a new process and a new connection, so this loop should show the IP changing:

for i in $(seq 1 5); do
  curl -s -x 'http://USERNAME-country-US:PASSWORD@GATEWAY_HOST:58971' \
    https://api.ipify.org
  echo
done

5. No DNS leaking locally

Using socks5h:// instead of socks5:// makes curl hand the hostname to the proxy, so local DNS never sees which site you're visiting.

curl -s -x 'socks5h://USERNAME-country-US:PASSWORD@GATEWAY_HOST:58971' \
  https://api.ipify.org

To be precise about current production behaviour: once the gateway receives a hostname it resolves it at the gateway and pins the target to the first resolved IP (to block DNS rebinding after the policy check). So:

• Your local DNS never sees the target domain — this holds
• Resolution does not happen in the region where the exit IP lives — don't rely on this for "resolve a CDN close to the exit region" use cases

6. Latency and throughput are acceptable

curl's timing fields show where the time actually goes:

curl -s -o /dev/null -x 'http://USERNAME-country-US:PASSWORD@GATEWAY_HOST:58971' \
  -w 'connect=%{time_connect}s appconnect=%{time_appconnect}s total=%{time_total}s\n' \
  https://example.com

• High time_connect → a network problem on the leg between you and the gateway; try a closer gateway node
• High time_appconnect → slow TLS handshake, usually on the exit-to-target leg
• Both normal but high total → the target site itself is slow

One script that runs everything

#!/usr/bin/env bash
set -euo pipefail

PROXY_USER="USERNAME"
PROXY_PASS="PASSWORD"
GATEWAY="GATEWAY_HOST:58971"
COUNTRY="US"

px() { echo "http://${PROXY_USER}${1}:${PROXY_PASS}@${GATEWAY}"; }

echo "== direct exit =="
curl -s https://api.ipify.org; echo

echo "== country targeting =="
curl -s -x "$(px "-country-${COUNTRY}")" https://ipinfo.io/json | head -c 200; echo

echo "== sticky session (expect 3 identical IPs) =="
for _ in 1 2 3; do
  curl -s -x "$(px "-country-${COUNTRY}-session-selftest-time-10")" https://api.ipify.org; echo
done

echo "== rotation (expect different IPs) =="
for _ in 1 2 3; do
  curl -s -x "$(px "-country-${COUNTRY}")" https://api.ipify.org; echo
done

If any step fails, look up the status code in the error reference or follow the troubleshooting flow.