Web Unlocker · mobile tier · carrier IPs shared by real phones
The Mobile Web Unlocker runs the same unlocker logic on 4G/5G carrier IPs: browser TLS fingerprints, retries on a fresh exit, and a real browser for JavaScript challenges. Use it for the strictest sites, when the residential tier keeps reporting access_denied.
# same proxy, mobile exits: add -tier-mobile
curl -k \
-x http://unlock.quantumproxies.io:9000 \
-U "unlock-XXXX-country-us-tier-mobile:PASSWORD" \
-H "x-qp-session: job42" \
https://example.com/
# REST: the same switch is one field
{ "url": "https://example.com/", "tier": "mobile" }

Mobile operators put thousands of phones behind a small pool of public addresses with carrier-grade NAT. One carrier IP is therefore shared by many real people at the same time, and blocking it would lock out paying customers of the site. Anti-bot systems know this and treat carrier ranges with far more caution than residential or datacenter ranges.
That is the whole difference between the tiers. The unlocker logic is identical; only the exit network changes. The Mobile Web Unlocker is for the sites whose problem is the IP range itself, not the fingerprint or the JavaScript challenge.
Every refused request comes back with a block class. access_denied means the site turned the request away without offering a challenge, and the unlocker's hint for that case is to try the mobile tier.
Other classes point elsewhere. js_challenge and fingerprint are what the browser escalation and fingerprint rotation are for, on either tier.
Everything the residential unlocker does applies here: six browser TLS fingerprints rotated on retry, up to three TLS attempts on fresh exits, escalation to a real browser for JavaScript challenges, POST sent exactly once, and blocked pages reported with x-qp-unlocker-blocked and a block class instead of a silent 200.
Sticky sessions work the same way with the x-qp-session header, and the forward proxy and REST endpoint are the same host and path. Switching tiers is a one-word change, so you can route per site in your own code.
Set the exit country with -country-xx in the username or the country field in REST. The mobile network covers 194 countries, with city-level targeting in the larger markets. A pinned session keeps one carrier exit for its lifetime; carriers may still rotate the underlying address, which is normal on mobile networks and one reason these IPs are trusted.
If you need plain mobile proxies without the unlocker logic, for example for an app or an antidetect browser that handles fingerprints itself, use the mobile proxy plans instead.

A web unlocker whose requests leave from 4G/5G carrier IPs instead of residential ones. It keeps the unlocker logic, browser TLS fingerprints, retries on fresh exits and a real browser for JavaScript challenges, and adds the trust that shared carrier addresses get from anti-bot systems.
For sites that refuse residential ranges, yes, because a carrier IP is shared by many real phones and blocking it hurts real users. For most other sites residential is enough. Use the block class the unlocker reports to decide per site.
They reduce the refusals that come from IP reputation.
Add -tier-mobile to the proxy username, for example unlock-XXXX-country-us-tier-mobile, or send "tier": "mobile" to the REST endpoint. Everything else, host, port, headers and sessions, stays the same.
No. The Mobile Web Unlocker has its own prepaid GB balance, separate from mobile proxy plans and from the residential unlocker, so each product is metered on its own.
Skip the marketing. QuantumProxies.io publishes a machine-readable site map, Markdown for every page, a free MCP server, and APIs billed from the same balance as your proxies.
Connect in one command: npx -y quantumproxies-mcp