Every mobile proxy provider makes the same core claim: your requests exit through real devices on real mobile networks, so target sites see the same class of IP address as an ordinary phone user. It is a claim you can verify in about sixty seconds, with free public APIs and one curl command. No account, no dashboard screenshot, no trust required.

We run a UK mobile proxy service, so we did the obvious thing: we pointed three free IP-intelligence APIs at our own exit IPs and pasted every response below, unedited. The same test works against any provider you currently use or are evaluating. If the "mobile" in your mobile proxy is real, these APIs will say so. If it is not, they will say that too.

The three APIs we asked

API Free tier What it reports
ip-api.com No key, 45 requests/minute, HTTP only mobile, proxy and hosting booleans, ISP, organisation, ASN
ipwho.is No key Geolocation plus connection.isp and connection.org (the carrier view)
api.ipapi.is No key, 10 fields per response when unauthenticated WHOIS-first company and ASN data; the full response adds datacenter, VPN and abuse flags

Each API builds its database differently: registry (WHOIS) records, BGP announcements, honeypots and threat feeds. That is the point. If one classifies an IP as mobile by accident, three independent classifications agreeing is a much stronger signal.

The setup

Every command below ran on 17 September 2026 with curl 8.5.0 against the public HTTPS proxy endpoint. Substitute your own credentials (shown here as USER:PASS) from whichever provider's dashboard you are testing:

curl -sS -x "https://USER:PASS@proxy.simplyproxies.com:6889" \
  "http://ip-api.com/json/?fields=status,country,city,isp,org,as,mobile,proxy,hosting,query"

The response came back in well under a second:

{"status":"success","country":"United Kingdom","city":"Leyton","isp":"British Telecommunications PLC","org":"EE Limited","as":"AS2856 British Telecommunications Limited","mobile":true,"proxy":false,"hosting":false,"query":"31.94.6.145"}

Result 1: the classification

Three booleans in the middle of that response are the whole story:

The org and as fields back it up: EE Limited, AS2856. That is a consumer mobile carrier's autonomous system, not a hosting company's. This is what a genuine mobile exit looks like to the databases that anti-bot vendors, ad platforms and fraud-scoring systems license and build on.

Result 2: the carrier view

ipwho.is returns geolocation plus the connection's ISP and organisation. Same proxy, new request:

{
    "ip": "92.40.171.95",
    "success": true,
    "country": "United Kingdom",
    "country_code": "GB",
    "city": "London",
    "connection": {
        "asn": 206067,
        "org": "Mobile Broadband Service",
        "isp": "Hutchison 3G UK Limited",
        "domain": "talksolution.co.uk"
    }
}

(Response trimmed for width; the full payload also includes continent, flag, calling code and timezone objects.)

This exit landed on Three: Hutchison 3G UK Limited is Three's operating company. Across all the requests in this test session, our exits spanned three UK carrier networks (EE, Three and Vodafone), which matters because carrier diversity is what makes a mobile pool look like a population of real subscribers rather than one network's worth of infra.

The third API, ipapi.is, returned this for another exit:

{"ip":"31.94.13.3","is_bogon":false,"company":"EE MOBILE","asn":"AS2856","city":"Royton","region":"England","country":"United Kingdom","lat":53.5651,"lon":-2.12267,"timezone":"Europe/London","docs":"https://ipapi.is/free-tier.html"}

Note the company value: EE MOBILE, straight from WHOIS records. Unauthenticated requests get this 10-field response; with a free account ipapi.is also returns is_datacenter, is_vpn, is_abuser and similar flags.

The lat/lon values are the database's estimate for the IP's registered network, not a device GPS fix: the same EE range resolved to Leyton (ip-api) and Royton (ipapi.is), two cities over 150 miles apart. Nothing on a device reports its location through the proxy.

Result 3: rotation

Bare requests rotate across the pool. Three requests in a loop:

for i in 1 2 3; do
  curl -sS -x "https://USER:PASS@proxy.simplyproxies.com:6889" \
    "http://ip-api.com/json/?fields=query,mobile,isp"
done

{"isp":"British Telecommunications PLC","mobile":true,"query":"31.94.32.113"}
{"isp":"British Telecommunications PLC","mobile":true,"query":"31.94.14.160"}
{"isp":"Hutchison 3G UK Ltd","mobile":true,"query":"92.40.171.95"}

Three requests, three different exit IPs, two carriers, mobile: true every time. This is the behaviour you want for scraping and polling workloads: per-request IP diversity without per-request setup, so per-IP rate buckets and IP-based blocklists keep missing you.

Result 4: sticky sessions

Some jobs need the opposite: the same exit IP for a while. Appending -session-<id> to the proxy username pins consecutive connections to one device for a sliding window (2 hours by default, 5 minutes to 12 hours selectable). The syntax is documented in our proxy docs.

Two HTTPS requests with the same session id:

{"mobile":true,"query":"148.252.165.71"}
{"mobile":true,"query":"148.252.165.71"}

The same IP, on Vodafone's network this time. The equivalent on the SOCKS5 port:

curl -sS -x "socks5h://USER-session-apidemo:PASS@proxy.simplyproxies.com:6890" \
  "http://ip-api.com/json/?fields=query,mobile"

{"mobile":true,"query":"31.94.14.160"}
{"mobile":true,"query":"31.94.14.160"}

One honest footnote: a session id pins within a protocol. The HTTPS port and the SOCKS5 port keep their own pinning state, so the same id does not guarantee the same device across both ports in the same window.

The control: what a datacenter IP looks like

For contrast, the same two APIs queried from a datacenter server with no proxy at all:

{"status":"success","country":"France","city":"Roubaix","isp":"OVH SAS","org":"OVH","as":"AS16276 OVH SAS","mobile":false,"proxy":false,"hosting":true,"query":"51.255.200.116"}

{"ip":"51.255.200.116","is_bogon":false,"company":"OVH SAS","asn":"AS16276","city":"Roubaix","region":"Hauts-de-France","country":"France","timezone":"Europe/Paris"}

mobile: false, hosting: true, company OVH SAS. This is what a bare VPS, a typical VPN endpoint and most cheap "datacenter proxies" look like to the exact same databases. Many bot walls key on that one boolean before they ever look at your headers or fingerprints.

What this test does and does not prove

We are the operator being tested, so the limits matter more than the highlights:

Check any provider in 60 seconds

  1. Classification: curl "http://ip-api.com/json/?fields=mobile,proxy,hosting,org,query" through the proxy. You want mobile: true, hosting: false, and a carrier-named organisation.
  2. Carrier and country: curl https://ipwho.is/ through the proxy. The ISP should be a mobile operator and the country should match what the provider promised.
  3. Rotation or stickiness: run the first command three times. Either you get different IPs (rotating pool) or, with a session id, the same IP on purpose. Getting one IP with no session suffix means you are pinned whether you asked or not.
  4. Baseline contrast: run the same commands without the proxy and compare. That is what your scraper looked like before.

If step 1 returns mobile: false or hosting: true, you are not on a mobile exit, whatever the plan is called.

Summary

Last verified 17 September 2026

Try It With Real UK Mobile IPs

Run the examples in this guide through genuine UK 4G/5G exits. 500 MB free, no card required.

Start Free Trial