Test a proxy by comparing one direct request with one proxied request from the same client, then confirm the observed exit IP and expected location. If the request fails, isolate authentication, connection, TLS or DNS, destination response, and application behavior in that order.
A proxy checker is evidence about a particular request, not a blanket promise of anonymity, speed, or future acceptance. Preserve the command, time, client, protocol, endpoint label, status, and a redacted error so another person can reproduce the result.
Start here
- Follow the direct-versus-proxied test sequence before testing a complex destination.
- Learn how to interpret proxy checker IP, speed, and anonymity signals.
- Use common proxy errors and fixes when a test fails.
- Resolve access problems with the proxy authentication guide.
Diagnose the layer that failed
| Observation | Likely layer | Next check |
|---|---|---|
| 407 or authentication challenge | Proxy access | Confirm username format, password, source-IP allowlist, and endpoint |
| Connection refused or timeout | Network or endpoint | Check host, port, protocol, firewall, and a known destination |
| TLS or certificate error | Tunnel or trust path | Compare direct TLS behavior without disabling verification |
| Proxy IP appears, target fails | Destination or workflow | Record the HTTP response and review destination rules |
| Command works, application fails | Application configuration | Compare protocol, DNS, environment, timeout, and authentication |
Do not collapse every non-success outcome into “bad proxy.” The distinction between a proxy-generated error, a transport failure, and a destination response determines who can fix it and what evidence support will need.
Choose a guide by symptom
No observable route change
Return to the working-test sequence. Confirm the client received the proxy configuration, compare direct and proxied results, and remove browser-extension or environment ambiguity.
Checker output is confusing
Use the checker interpretation guide to separate observed IP, location databases, latency, and forwarding signals. Repeat measurements rather than treating one timing as a benchmark.
A request returns an error
Use the common-errors guide to move from endpoint and authentication through DNS, TLS, HTTP response, and application parsing. Change only one variable between attempts.
Authentication fails intermittently
Use the authentication guide to choose credentials or source-IP allowlisting. Check changing egress IPs, copied whitespace, and secret encoding before rotating credentials.
Recheck the client configuration
Use the browser and operating-system setup guide when a command works but the application does not honor the expected route.
Reproduce the request from a terminal
Use the cURL proxy guide for a small, redacted control request before changing several application settings at once.
Use the result in context
- Revisit Proxy Basics when protocol choices are unclear.
- Correct the client in Proxy Setup and Developer Guides.
- Turn a proven route into controlled checks with Platform and Regional Proxy Testing Guides.
Compare pricing after a small validation
Once one endpoint works in the intended client and destination class, compare Mexela proxy pricing against the required endpoint count, location, protocol, and support model. A larger plan will not correct a protocol mismatch or application bypass.
Frequently asked questions
Does a changed IP prove every request uses the proxy?
No. It proves the tested request used a different observed path. Test each relevant client and traffic type, especially when DNS or browser traffic may take another route.
Should TLS verification be disabled to fix errors?
No. That hides an important security signal. Identify whether the client, tunnel, local inspection layer, or destination certificate caused the failure.
What should a support report include?
Include the endpoint label, protocol, time and timezone, client, redacted error, destination category, and whether a neutral checker worked. Never include passwords.