Contents
Checking that your proxy works — and why half the tests lie
A proxy test that fails does not always mean "the proxy is broken". It often means "the testing tool is unsuitable". The difference costs hours.
update Updated
The test, in one command
curl -x socks5h://USERNAME:PASSWORD@frproxy.com:15002 https://api64.ipify.org
Expected output: an IP address. If it is your proxy's and not yours, all is well.
socks5h, not socks5. The h tells curl to have the domain name resolved by the
proxy. Without it your machine resolves locally and your internet provider sees what you are
browsing. See HTTP or SOCKS5.
For an HTTP port:
curl -x http://USERNAME:PASSWORD@frproxy.com:15001 https://api64.ipify.org
⚠️ The trap that makes you conclude wrongly
Careful: api.ipify.org only answers over IPv4.
If your proxy exits over IPv6, which is the case with our dual-stack offers and the normal case at several French mobile carriers, the test fails while the proxy works perfectly. The service simply cannot answer.
Use api64.ipify.org (IPv4 and IPv6), or cross-check with a test that does not depend on
a third-party service:
# 301 = TCP reaches Cloudflare. No DNS, no third-party API involved.
curl -x socks5h://USER:PASS@frproxy.com:15002 -o /dev/null -w '%{http_code}\n' -k https://1.1.1.1
What to check, in order
| # | Question | How |
|---|---|---|
| 1 | Does the proxy answer? | The curl command above |
| 2 | Is the IP French? | https://ipinfo.io/json through the proxy, country field |
| 3 | Is it seen as mobile? | The org field must name a carrier (Orange, SFR, Free, Bouygues) |
| 4 | Is DNS leaking? | https://dnsleaktest.com from the configured browser |
| 5 | Is WebRTC leaking? | https://browserleaks.com/webrtc, see the dedicated article |
Points 4 and 5 are the ones people forget, and they are the two that actually give you away.
From the panel
My proxies shows, for each line, the public IP as seen by the engine, the server-side
truth, independent of what your machine believes. If the panel shows one IP and your test shows
another, the fault is in your local configuration, not the proxy.
Checking without a command line
If you would rather use a page than a terminal, open one of these addresses in the window configured with the proxy:
| Address | What it shows you |
|---|---|
api64.ipify.org |
your exit IP, over IPv4 as well as IPv6 |
iphey.com |
the IP, the country, and whether your browser is consistent |
browserleaks.com/ip |
the IP, the DNS server in use and WebRTC leaks |
For throughput, an ordinary speed test will do. Run it two or three times: on a mobile line a single measurement varies a lot from one run to the next.
Two rules of method
- Qualify the tool before you qualify the fault. A negative test only becomes a conclusion once the tool is known good. Run the command without the proxy first: if it already fails, the proxy is not the problem.
- Separate measured, correlated and assumed. "The proxy is slow" and "the page takes a while to render" are not the same claim.
See also: Common errors · Changing your IP
Need a French mobile proxy? A real French 4G/5G line, one HTTP port and one SOCKS5 port, IP rotation on demand.
See the offersarrow_forward