Transport diagnostics
The scheme controls how the checker reaches the proxy and where target names are resolved. An explicit scheme is part of the endpoint contract, not decorative input.
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
Use http:// for a plain HTTP proxy transport that tunnels HTTPS targets with CONNECT. Use https:// when the connection from the checker to the proxy itself must be protected by TLS with hostname verification and SNI. Use socks5:// for SOCKS5 TCP with checker-side target DNS, or socks5h:// for SOCKS5 TCP with proxy-side target DNS. Auto makes only bounded HTTP/SOCKS5 attempts and never silently upgrades to HTTPS or changes to SOCKS5H. The checker does not test UDP ASSOCIATE.
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 |
|---|---|---|
| Explicit scheme | The proxy transport and, for SOCKS5 forms, the requested target-DNS mode. | That the endpoint supports another transport on the same port. |
| Transport that worked | Which bounded connection mode completed this server-side HTTPS test. | Support in every browser, operating system, library, UDP application, or future session. |
| TLS failure | A required TLS handshake or certificate validation did not complete for this attempt. | Whether the provider intended plain HTTP on that port or whether another client disables validation. |
| SOCKS target-DNS mode | Whether the checker or SOCKS proxy is asked to resolve the fixed destination hostname. | The DNS behavior of the visitor's browser, operating system, or unrelated applications. |
Diagnostic workflow
Keep the endpoint, transport, target, and evidence boundary explicit so a retry remains comparable.
Copy the exact public endpoint transport. A port number alone is not reliable proof of HTTP, HTTPS, or SOCKS5 behavior.
Use https:// only when the checker must establish TLS to the proxy itself. The hostname is retained for certificate verification and SNI even when its address is resolved and pinned for the connection.
Use socks5:// when checker-side target resolution is intended and socks5h:// when the proxy should resolve the fixed target. Both modes test TCP, not SOCKS UDP association.
Without an explicit scheme, Auto starts with SOCKS5 on ports 1080/1081 and HTTP elsewhere, then tries the other mode once after a qualifying failure. HTTPS and SOCKS5H require explicit schemes.
Providers, data fields, timing boundaries, timeouts, privacy, and limitations are published as versioned JSON.
Interpretation reference
These labels describe the checker-to-proxy connection. Every successful mode still carries an HTTPS request to the fixed exit or selected target service.
| Input mode | Checker-to-proxy transport | Target DNS and important boundary |
|---|---|---|
| http:// | Plain TCP to an HTTP proxy; HTTPS destinations use an HTTP CONNECT tunnel. | CONNECT carries the fixed target authority to the proxy; the checker does not expose the proxy operator's resolver implementation. |
| https:// | TLS to the proxy with hostname verification and SNI, then HTTP proxy semantics/CONNECT inside it. | The explicit secure transport is preserved; a failed TLS handshake is not retried as plain HTTP. |
| socks5:// | SOCKS5 TCP negotiation, with username/password authentication when supplied. | The checker resolves the fixed target hostname before asking the proxy to connect. |
| socks5h:// | SOCKS5 TCP negotiation, with username/password authentication when supplied. | The target hostname is sent to the proxy for remote resolution. |
| Auto | At most one HTTP and one SOCKS5 attempt in a documented port-based order. | It does not attempt HTTPS proxy TLS, SOCKS5H, UDP, arbitrary authentication methods, or unlimited retries. |
Troubleshooting
Keep credentials private and change one variable at a time.
Likely meaning: The port may expose a plain HTTP proxy rather than TLS to the proxy, or its certificate/hostname validation may fail.
Next check: Use the provider's documented scheme and hostname; never downgrade a required secure transport merely to obtain a green result.
Likely meaning: Checker-side target DNS succeeds while the proxy-side resolver or remote-name command does not.
Next check: Confirm the provider supports remote target DNS and keep the mode required by the actual application.
Likely meaning: The first SOCKS5 attempt failed and the bounded HTTP fallback completed.
Next check: Retest with an explicit scheme before configuring the endpoint in production.
Likely meaning: The browser may use system settings, extensions, certificate policy, authentication negotiation, or DNS behavior that this server-side checker does not reproduce.
Next check: Compare the exact scheme, hostname, port, authentication method, and DNS mode rather than the product label alone.
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 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