Run these in order from the machine that will run the job. Each one catches a class of fault that is cheap to find now and expensive to find in production.
The checks
- Exit address. Request an address-echo service through the proxy and confirm it is not your own.
- Rotation. On a rotating product, repeat the request and confirm the address changes; on a sticky session, confirm it does not.
- Protocol. Try HTTPS targets, not only HTTP, and the SOCKS5 scheme if you plan to use it.
- DNS. Compare local and proxy-side resolution for a hostname that you expect to differ by region.
- Location. Look up the exit address in two geolocation databases and note where they disagree.
- Timing. Record connect, TLS and first-byte times over a few dozen requests and read the spread.
- Failure handling. Point the job at a URL that returns 403 and one that times out, and confirm it logs and backs off instead of looping.
for i in 1 2 3; do
curl -s -x "$PROXY_URL" https://httpbin.org/ip
done
curl -s -o /dev/null -x "$PROXY_URL" \
-w 'connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' \
https://example.com/Then run the measurement harness on your real targets. A setup that passes these checks can still fail on a hard target, and only the harness tells you which.