Working, encrypted and trusted mean different things
Working means a request succeeded under particular test conditions. Encrypted describes protection on a specific part of the connection. Trusted describes your reason to rely on an operator. One label cannot stand in for the other two.
Each endpoint in our checked proxy catalog must carry two HTTPS requests with normal certificate verification and report changed exit addresses. Those observations establish reachability for the probes at that moment. They do not audit the operator, measure logging or make the endpoint suitable for confidential accounts.
What HTTPS protects through a proxy
For an ordinary HTTP CONNECT or unauthenticated SOCKS proxy carrying destination HTTPS, TLS protects the application content between your client and the destination when certificates are correctly verified. Connection metadata remains relevant: the intermediary handles the connection and can observe such details as timing and the destination it is asked to reach.
Plain HTTP does not provide the same content protection. Stop if an unfamiliar proxy causes certificate errors or asks you to install a root certificate. Disabling verification removes a protection that our own checks require. For a protocol explanation, read how CONNECT tunnels work.
Why we do not promise elite anonymity or no logging
An exit-IP change does not prove that all identifying information disappeared. Accounts, cookies, browser behavior and application settings can still distinguish a session. A short probe cannot prove what the proxy operator stores or whether other applications bypass the proxy.
For that reason, we do not copy an “elite” or “anonymous” source label into an independently verified anonymity claim. Country metadata also has limits: an endpoint’s listed country may differ from the location a destination assigns to its observed exit. A location flag is not a privacy certification.
A practical workflow for a non-sensitive test
- Choose a compatible protocol and a result with a recent check time. Open its detail card and inspect the attempt count.
- Use a separate test profile or an explicit per-request proxy setting without personal cookies or credentials.
- Compare the visible exit with a direct baseline, keep HTTPS validation enabled and use a short timeout.
- Restore your previous client settings when finished. If the endpoint fails, try a fresh result instead of weakening certificate checks.
The Firefox guide explains browser setup and restoration. The troubleshooting guide separates timeouts, protocol mistakes and certificate failures.
Would a free VPN remove these concerns?
A VPN can encrypt a tunnel to its endpoint and cover more device traffic, depending on routing and DNS configuration. It still introduces an operator you must evaluate. A public VPN connectivity check is not an audit of that operator’s logging practices either.
Use Proxy vs VPN to compare the connection models. If you need a VPN profile, browse the OpenVPN catalog or other tunnel protocols. If you need an application proxy, use the HTTP and SOCKS catalog. For sensitive work, choose an operator on grounds beyond a successful public test.
Inspect the evidence and report incorrect information
Our methodology describes probe destinations, check expiry and untested capabilities. The source page identifies discovery feeds and checker status. Detailed cards retain recent attempts so a failure does not silently become a success claim.
If you operate a listed endpoint or notice incorrect metadata, use Contacts with the public address, protocol and approximate time. Leave out passwords, tokens and private browsing data.