Skip to content

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

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.

We lost an entire measurement campaign to this detail: a proxy declared "down" was serving traffic without a single error.

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.

Three rules of method

  1. 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.
  2. One sample is not a rule. A throughput measured once says nothing about variance: the same phone gave 152 then 75 Mbit/s ten minutes apart.
  3. 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 line, one HTTP port and one SOCKS5 port, IP rotation on demand.

See the offersarrow_forward
grid_viewWiki