Failure diagnostics
A diagnostic code describes the evidence this checker obtained. It does not identify every possible root cause, and it never needs your password in a screenshot or support message.
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
Start with the exact error code, selected transport, selected target, and a credential-free endpoint label. Format and private-address failures happen before a proxied request. DNS, authentication, connection, TLS, timeout, and response failures happen at different network stages. A target response outside the accepted range means that one lightweight request was not accepted; it does not prove the exit IP is universally blocked.
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 |
|---|---|---|
| Status | The broad outcome category shown by this checker, such as invalid, offline, timed out, or working. | The responsible operator, the endpoint's future availability, or whether another client will behave identically. |
| Error code | The parser, resolver, transport, authentication, target, or response stage associated with the observed failure. | A complete packet-level root cause or a provider-wide incident. |
| HTTP target status | The status in the first response headers returned for the selected target request. | That the destination banned the proxy; 4xx and 5xx responses have many possible causes. |
| Credential-free label | Which submitted line number and masked endpoint the result belongs to. | The submitted username or password, which must remain private. |
Diagnostic workflow
Keep the endpoint, transport, target, and evidence boundary explicit so a retry remains comparable.
Check the line format, bracket IPv6 literals, keep the port within 1–65535, and percent-encode reserved characters inside URL-form credentials. Do not post the raw credential string.
Replace Auto with the transport your provider documents. Use http:// for plain HTTP proxy transport, https:// for TLS to the proxy, socks5:// for checker-side target DNS, or socks5h:// for proxy-side target DNS.
Run General HTTPS connectivity first. If it succeeds, run the same endpoint against the selected Google or Wikipedia target so a destination response is not confused with a dead proxy.
Keep the endpoint, transport, target, and runner stable for a repeated check. If several settings change together, a different result cannot be attributed to one cause.
Providers, data fields, timing boundaries, timeouts, privacy, and limitations are published as versioned JSON.
Interpretation reference
Use the code as a bounded observation. The suggested next check is designed to narrow the failure without revealing credentials or assuming the provider is at fault.
| Code | Observed evidence | Safe next check |
|---|---|---|
| INVALID_FORMAT | The line could not be parsed into a supported public proxy endpoint. | Compare it with the accepted examples; check brackets, scheme, port, and credential separators. |
| PRIVATE_ADDRESS | The endpoint was private, reserved, or did not resolve exclusively to public addresses. | Use the public hostname supplied by the provider; do not submit loopback, LAN, or internal service addresses. |
| DNS_FAILED | The checker could not resolve the submitted proxy hostname. | Verify spelling and public DNS records from an independent resolver, then retry. |
| AUTH_REQUIRED | The proxy requested authentication or rejected the supplied authentication exchange. | Verify username format, password encoding, IP-whitelist mode, and product-specific authentication rules privately. |
| CONNECT_REFUSED | The remote host refused or closed the proxy connection. | Confirm host, port, service state, allowlists, and whether the provider expects another transport. |
| NETWORK_UNREACHABLE | The checker could not establish a route to the proxy host. | Check address-family reachability and whether the endpoint is restricted to a private or provider network. |
| TLS_FAILED | A required TLS handshake or certificate verification failed. | Confirm whether the proxy transport is HTTPS, whether the hostname matches its certificate, and whether the provider requires a different TLS endpoint. |
| TARGET_DNS_FAILED | The selected target hostname could not be resolved in the active transport's documented DNS mode. | Keep the proxy transport fixed and verify whether checker-side or proxy-side target DNS is intended. |
| TARGET_CONNECT_FAILED | The proxy route worked for the exit check but did not establish the selected target connection. | Treat this as target-specific transport evidence and retry General HTTPS connectivity before changing credentials. |
| TARGET_TLS_FAILED | The selected target's HTTPS handshake failed after the neutral exit check succeeded. | Compare target policy and the active transport; do not report the proxy endpoint itself as universally offline. |
| TARGET_TIMEOUT | The selected target request produced no response headers within eight seconds. | Retain the successful exit evidence and retry the same target once; do not invent an HTTP status. |
| TARGET_FAILED | The selected target request failed without a more specific public target-stage code. | Retest one endpoint with the same explicit transport and record only the non-secret code, target, and time. |
| TARGET_NOT_ACCEPTED | The selected target returned response headers outside the accepted 2xx/3xx range. | Record the status and retry General HTTPS connectivity; treat the result as target-specific, not proof of a ban. |
| TIMEOUT | One proxied request attempt did not finish within eight seconds. | Retry at another time and compare an explicit transport; do not treat one timeout as a throughput measurement. |
| BAD_RESPONSE | The exit-IP service returned a non-200, oversized, malformed, or non-public address response. | Retry once and compare another endpoint; persistent results may indicate response rewriting or an upstream service problem. |
| CANCELLED | The run was cancelled before this check produced a normal terminal result. | Start a new run if evidence is still needed; do not reinterpret cancellation as endpoint failure. |
| UNKNOWN | The failure did not match a more precise public category. | Retest one endpoint with an explicit transport and retain only non-secret timestamps, codes, and target details for support. |
Troubleshooting
Keep credentials private and change one variable at a time.
Likely meaning: Auto is a bounded convenience sequence and does not guess TLS-to-proxy or remote-DNS SOCKS modes.
Next check: Keep the working explicit scheme in the client configuration instead of relying on port inference.
Likely meaning: The proxy reached the neutral exit check, while the selected destination returned different response headers.
Next check: Review the status, destination rules, region, rate, and client behavior; do not label the endpoint dead.
Likely meaning: The route, proxy pool, exit, queue, or destination may be variable.
Next check: Repeat a fixed explicit test and compare the success count and median response time instead of one run.
Likely meaning: The proxied exit check succeeded but the separate direct GeoJS enrichment did not return usable fields.
Next check: Treat connectivity as observed and location as unavailable; retry rather than inventing geography.
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.
Separate response timing from throughput and compare repeated measurements correctly.
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