The goal is not to prove that every proxy works forever. It is to measure the properties that matter for your target and to catch obvious problems early.
Start with a connectivity check
Send a request to a lightweight HTTPS endpoint that echoes the client IP. A successful response proves three things at once: the proxy accepts your credentials, it can reach the public internet, and the exit IP is the one you expect.
If the response times out, separate the layers. Test the proxy host and port directly, then test authentication, then test the destination. A timeout at the first step is a connectivity problem; an immediate 407 is an authentication problem.
curl -sS -x http://USERNAME:PASSWORD@proxy.graviix.com:8080 \
-H "X-Graviix-Country: US" \
https://httpbin.org/ipMeasure latency the right way
A single ping is not a proxy benchmark. Measure time to first byte and total request time over several attempts, and compare against a direct request to the same destination. The difference is the proxy overhead, which is the number that matters for your pipeline.
Test from the same machine and network you will use in production. A proxy that feels fast from a laptop on office Wi-Fi can behave differently from a worker in a cloud region.
Verify anonymity and headers
Check which headers the destination can see. A well-run proxy should not add forwarding headers that reveal your origin. Inspect the request with a header echo endpoint and look for clues such as Via, X-Forwarded-For, or a client IP that does not match the proxy exit.
This is also the moment to check DNS behaviour. If DNS resolution happens on your machine instead of the proxy network, the destination can still infer your location through the resolving network. Use a proxy that handles DNS for the protocols you rely on.
Test geography and stability
Geolocation databases disagree, and a country label is not a guarantee. Query an IP intelligence endpoint from inside the proxy and confirm the country and city match your targeting request. If you need city-level accuracy, test the exact city you plan to use.
Finally, run a soak test. Send a steady stream of requests for ten to thirty minutes and track the success rate, latency percentiles, and how often the exit IP changes. A list that passes a single request but degrades after a hundred is not ready.
- Success rate over at least a few hundred requests.
- Latency at the median and at the 95th percentile, not just the average.
- Exit IP consistency for sticky sessions and variation for rotating sessions.
- Header leakage and DNS resolution behaviour.
Test at a scale that matches production
A test with one worker underestimates contention. Real pipelines run several workers at once, and the proxy network, local network, and target all behave differently under parallel load. Repeat the test with the concurrency you intend to use, even if the sample is small.
Watch for failures that only appear in parallel: connection resets, elevated 429 responses, and latency spikes. These are exactly the conditions that make a list look fine in a spreadsheet and fail in production.
What to put in a test report
Write down the scope before testing so the result cannot be reinterpreted later. A useful report states the proxy source, the date and time, the test destination, the concurrency, and the number of attempts. Then include the success rate, latency percentiles, and any header leakage you observed.
Add a short interpretation rather than raw numbers alone. State whether the list is suitable for the intended target and under which conditions. The next person should be able to repeat the test and compare results without asking questions.
Separating proxy faults from target faults
A failure is not automatically the proxy's fault. The same request may fail because the target is slow, because the path changed, or because the local machine lost connectivity. Test each layer in order: a direct request from the same machine, a request through the proxy to a neutral endpoint, then a request through the proxy to the target.
If the neutral endpoint works and the target fails, the proxy path is functional and the issue is target-specific. If the neutral endpoint fails too, the problem is in the proxy, credentials, or local network. This simple ladder saves hours of tuning the wrong component.
Record the outcome of each step. A report that shows the ladder makes it obvious where the fault sits, even to someone who was not present during testing.
Key takeaways
- Test connectivity, authentication, latency, headers, and geography as separate steps.
- Use a soak test; single requests hide instability.
- Compare proxy timing against a direct baseline before drawing conclusions.
Frequently asked questions
Can I test proxies from a browser?
For quick checks, yes. Browser-based tools can validate a list and measure latency from your own connection. For production decisions, run the same tests from the environment that will send the real traffic.
Why do some proxies pass a test but fail on the real site?
The test endpoint is usually tolerant. Real targets add bot management, rate limits, and fingerprint checks. Always validate against the actual destination with a small sample before scaling.
How many requests make a reliable test?
There is no universal number. A few hundred requests over a sustained period is a reasonable starting point for stability, plus targeted checks for the specific behaviours your workflow depends on.
Need proxies for this workflow?
Graviix provides residential, mobile, datacenter, and static ISP proxies with country and city targeting, rotating or sticky sessions, and a documented HTTP API.
