Destination evidence
A target check makes one lightweight server request after the neutral exit check. Its response headers describe that request, not every page, account, browser, or future visit.
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
The checker first requests IPify through the proxy and validates the public exit IP. If Google or Wikipedia is selected, it then starts a second proxied HTTPS request and stops timing when the first response headers arrive; it does not download the target body. A 2xx or 3xx response is reported as accepted. A 4xx or 5xx response is reported as not accepted with its HTTP status. Neither result proves universal access, a destination-wide block, browser compatibility, or anonymity.
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 |
|---|---|---|
| Neutral exit check | The proxy completed the fixed IPify HTTPS request and returned a valid public exit address. | That Google, Wikipedia, or the visitor's actual destination will accept the same route. |
| 2xx/3xx target headers | The selected destination returned an accepted-range initial response to this lightweight request. | That redirects complete, page bodies load, JavaScript runs, accounts remain usable, or future requests succeed. |
| 4xx/5xx target headers | The selected destination returned a client- or server-error status for this request. | That the proxy IP was banned; authentication, rate limits, URL policy, maintenance, headers, or automation controls can produce the status. |
| Target response time | Elapsed checker-server time until the initial response headers arrived through the proxy. | Body throughput, full page load, browser rendering, CAPTCHA completion, or application success. |
Diagnostic workflow
Keep the endpoint, transport, target, and evidence boundary explicit so a retry remains comparable.
The fixed IPify request must return HTTP 200 with a valid public address before target evidence is meaningful. A failed exit check remains a proxy or upstream failure, not a target result.
Google uses its lightweight generate_204 endpoint. Wikipedia uses its public homepage. The checker records only initial response-header status and timing and does not download the target body.
Initial 2xx and 3xx responses are accepted. Initial 4xx and 5xx responses are not accepted. Redirects are not followed as a browser journey, and no cause is inferred from the status alone.
Use an authorized client test with the real destination, method, headers, session, and rate policy. Do not add arbitrary private or user-supplied target URLs to this public checker.
Providers, data fields, timing boundaries, timeouts, privacy, and limitations are published as versioned JSON.
Interpretation reference
The status family is evidence from one request. The next step depends on the destination and authorized workload, not a universal good/bad label.
| Response | Checker interpretation | Important qualification |
|---|---|---|
| 2xx | Accepted for this target request. | The target body is not downloaded, so page content and application behavior remain untested. |
| 3xx | Accepted-range initial response. | The redirect chain is not followed; its destination and final outcome remain unknown. |
| 400 / 404 | Not accepted for this request. | The path, method, headers, or destination policy may explain the response; it is not automatic IP-block evidence. |
| 401 / 403 | Not accepted for this request. | Authentication, authorization, automation controls, region, reputation, or request shape may be involved. |
| 407 | Proxy authentication failed before usable target evidence. | Review the proxy credentials and authentication mode, not the destination account. |
| 408 / 429 | Not accepted or rate-limited for this request. | Retry policy and destination limits matter; do not increase traffic to force a different result. |
| 5xx | The target returned a server-error response. | This may be transient or target-side and does not prove the proxy route caused it. |
| No headers before timeout | No target response evidence was obtained within eight seconds. | Network delay, proxy behavior, TLS, or destination reachability may be involved; no HTTP status can be inferred. |
Troubleshooting
Keep credentials private and change one variable at a time.
Likely meaning: The neutral route works while Google declined or limited this lightweight request.
Next check: Respect the destination's terms and rate limits; test the authorized real workflow without calling the proxy dead or universally blocked.
Likely meaning: The checker records only the initial redirect and does not follow cookies, scripts, challenges, or the final page.
Next check: Inspect the browser's full redirect chain and final response under the same authorized route.
Likely meaning: Destinations use different networks, policies, reputation data, headers, and application controls.
Next check: Treat Wikipedia as evidence only for Wikipedia's fixed request and test the actual destination separately.
Likely meaning: The exit, route, rate state, destination service, or policy decision may have changed.
Next check: Record repeated results, exit changes, timestamps, and request rate without publishing the raw exit address or credentials.
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 resourceSeparate response timing from throughput and compare repeated measurements correctly.
Open resourceUnderstand explicit transports, SOCKS5 DNS modes, and bounded Auto behavior.
Open resourceAfter checking a proxy endpoint, compare browser-visible IPv4, IPv6, WebRTC, and DNS routes.
Open resource