Performance methodology
The checker times small server-side requests through a proxy. It does not transfer enough controlled data to measure bandwidth, sustained throughput, or the experience from your device.
This method is maintained by the TrueProxies product team. The named maintainer is not presented as an independent auditor or third-party certification body.
Quick answer
Exit response time begins immediately before the checker opens the proxied request and ends after the small IPify JSON body is received and validated. Target response time ends when the selected target's response headers arrive; the target body is not downloaded. Proxy-host DNS resolution, queue time, GeoJS enrichment, rendering, and download throughput are outside those timers. Compare repeated results from the same runner and target, then report a median and sample count instead of calling one low value the fastest proxy.
Evidence boundaries
A trustworthy proxy diagnostic states exactly what one result shows and keeps broader claims outside the verdict.
| Signal | What it establishes | What it does not establish |
|---|---|---|
| Exit response time | Elapsed checker-server time for the proxy connection, tunnel/TLS work, request, and validated small exit-IP response. | Target-site latency, user-device latency, bandwidth, sustained throughput, or queue duration. |
| Target response time | Elapsed checker-server time until the selected target's initial response headers arrive through the same proxy transport. | Page load time, response-body transfer speed, rendering time, JavaScript completion, or browser interactivity. |
| Repeated sample | How variable the same defined check was during the sampled window. | A provider-wide service level or performance from untested locations and destinations. |
| Timeout | That one proxied request attempt did not finish within the eight-second boundary. | A numeric latency above eight seconds, zero throughput, or permanent endpoint failure. |
Diagnostic workflow
Keep the endpoint, transport, target, and evidence boundary explicit so a retry remains comparable.
Use the same endpoint, explicit transport, selected target, and approximate time window. A different target or checker region changes the network path being timed.
Run at least five comparable checks and retain timeouts and failures. Removing slow or unavailable attempts makes the sample look better than the observed route.
Use sample count, successful count, median, interquartile range, and optionally p95 when the sample is large enough. Avoid ranking endpoints from one request.
A bandwidth test needs a controlled payload, transfer duration, byte count, concurrency policy, and authorized destination. This checker intentionally does not perform that workload.
Providers, data fields, timing boundaries, timeouts, privacy, and limitations are published as versioned JSON.
Interpretation reference
Several durations can occur during one run. Only the two proxied request measurements are displayed as response times.
| Duration | Included | Excluded / interpretation |
|---|---|---|
| Queue wait | Time before a worker begins the endpoint. | Not included in exit or target response time; it describes checker load, not proxy latency. |
| Proxy-host DNS | Resolution of the submitted proxy hostname by the checker. | Occurs before the proxied request timer and must not be presented as measured proxy response time. |
| Exit response | Proxy connection, applicable TLS/CONNECT/SOCKS negotiation, HTTPS request, small body receipt, and IP validation. | Does not include GeoJS, target testing, rendering, or throughput. |
| Geo enrichment | Direct lookup of the observed exit IP by the checker. | Separate best-effort work; absent location fields do not change the exit response timer. |
| Target response | Second proxied request until Google or Wikipedia response headers arrive. | No target body, redirect chain, browser rendering, or JavaScript execution is timed. |
| Whole job | Queueing plus all endpoint checks and polling for the submitted list. | Useful for workflow duration, but not comparable with one endpoint's network response time. |
| Throughput | Bytes transferred per unit of time under a controlled payload and policy. | Not measured by this tool; no Mbps claim can be derived from its small requests. |
Troubleshooting
Keep credentials private and change one variable at a time.
Likely meaning: The neutral exit service and selected destination use different routes, servers, controls, or response behavior.
Next check: Repeat both measurements and optimize for the actual destination rather than the neutral endpoint alone.
Likely meaning: Shared capacity, rotating exits, routing, congestion, TLS setup, or destination load may change between attempts.
Next check: Increase the repeated sample and report its spread; inspect whether the exit IP changed.
Likely meaning: IP geolocation is approximate and network topology does not follow geographic distance directly.
Next check: Use measured repeated target timing from the relevant runner rather than city distance as the decision rule.
Likely meaning: Queueing, bounded worker capacity, retries, GeoJS lookups, target checks, polling, and failures add whole-job duration.
Next check: Treat completion time as workflow capacity and per-result timing as a separate network measurement.
These standards define the protocol and response semantics used to qualify the checker evidence.
Continue diagnosing
Each resource answers a separate question and links back to the one canonical proxy checker.
Map each diagnostic code to the failed stage and a safe next check.
Open resourceUnderstand explicit transports, SOCKS5 DNS modes, and bounded Auto behavior.
Open resourceInterpret response-header evidence from Google or Wikipedia without calling every rejection a block.
Open resourceAfter checking a proxy endpoint, compare browser-visible IPv4, IPv6, WebRTC, and DNS routes.
Open resource