4G/5G Mobile Proxy Farms: Detection When Every IP Is a Real Carrier

A mobile proxy farm is a rack of phones or LTE modems, each with a SIM card, sold as a proxy service. Traffic sent through it leaves the internet from a real mobile carrier, on the same address ranges the carrier’s ordinary subscribers use. Many services let the customer rotate to a new IP on demand by reconnecting the modem to the network.

For anyone relying on IP reputation, this is the worst case. The address is not a datacenter, not a known VPN, and not on any list. It is also shared with people you want as customers.

Why carrier IPs defeat reputation

Mobile networks typically run carrier-grade NAT (CGNAT): many subscribers share a public IPv4 address at the same time, and the mapping changes as devices reconnect. That has two consequences for fraud tooling.

Blocking is collateral damage. An IP that just sent you twenty fake signups may, a moment later, carry an ordinary customer’s checkout. Block the IP and you block them. Block the range and you block a city.

Reputation never accumulates. A farm that rotates on every request spreads its abuse across a pool of addresses so large and so shared that no single one looks bad for long.

So the traditional response, adding the IP to a deny list, is both harmful and ineffective here. The mobile carrier IP fraud post goes deeper into why carrier traffic needs gentler handling in general.

What a farm cannot rotate

The IP is the farm’s product. Everything else about the client is the customer’s problem, and that is where detection should shift its weight.

The client’s TLS fingerprint

The proxy carries the connection; it does not change who made it. A Python script using an HTTP library, routed through a 4G modem, still opens TLS like a Python HTTP library. When that request claims a Chrome user agent, the mismatch is visible in the JA4 fingerprint. Prynt’s tlsFingerprint Smart Signal and the TLS_AUTOMATION reason code capture exactly this. The JA4 value comes from the network edge, so it is available when traffic passes through an edge connector, such as the Cloudflare Worker, that forwards it.

There is one important exception: some proxy setups terminate and re-originate connections, and fully browser-based automation has a genuine browser handshake. JA4 is strong against HTTP clients and weaker against real browsers, so treat it as one input.

Device and network consistency

A farm sells IPs in a region; it does not move the buyer’s computer there.

• Timezone vs IP location. A browser on one continent’s time behind a carrier IP on another is a common mismatch.
• Locale and language. The same principle, weaker but cheap.
• Mobile network, desktop device. A carrier IP serving a desktop browser is perfectly normal for people on phone hotspots. A carrier IP serving a desktop browser with a virtual machine signature, and no mobile hardware traits, is much less so.
• Location spoofing on mobile. If the farm customer is running your mobile app in emulators, the mobile SDK’s emulator and LOCATION_SPOOFING signals report it.

None of these is conclusive alone. Travelers have mismatched timezones and many people use hotspots. In combination, they separate a farm customer from a commuter.

Per-device velocity

This is the signal that matters most. The farm rotates IPs so that no IP has velocity. But the farm customer’s devices are not rotating nearly as fast. A single visitorId producing many identifications across many carrier IPs in an hour is the signature of a rotating proxy in front of one machine.

Look at it two ways:

• Identifications per device per window. VELOCITY fires on bursts from one device.
• Accounts per device. Fresh IPs make each signup look new, but accountsOnDevice still lists every account you have attached to the device. MULTI_ACCOUNT fires at two or more distinct accounts within 30 days, and ACCOUNT_SHARING at more than three in 24 hours.

Operators who understand this create a fresh browser profile per account. That moves the problem rather than solving it: many new devices with identical environments, identical behavior and the same carrier ranges, which is what rotating proxy detection looks for.

Proxy and automation signals

Prynt’s proxy and residentialProxy signals look for evidence of relaying beyond the IP’s owner, and the bot, behavioral and tampering signals look at the client itself. A mobile IP with automation signals is a very different event from a mobile IP alone. The residential proxy detection post covers the overlap; mobile proxies are the hardest member of the same family.

Rules that put weight in the right place

In the console rules engine, conditions combine with eq, gt, gte and similar operators over fields such as velocity, multiAccount, distinctAccounts30d, deviceSpread, virtualMachine, bot, tampering and riskScore. A rule set for a signup endpoint under mobile-proxy attack might read:

• Block when bot is true, or distinctAccounts30d is at least 3.
• Challenge when velocity (the device’s recent identification count) is greater than a threshold that fits your traffic, or virtualMachine is true.
• Tag signups where multiAccount is true for review, without blocking.

Block wins over an earlier challenge, so the order of evaluation is safe. The same logic in your backend, reading the event directly:

const event = await prynt.getEvent(requestId);    // GET /v1/events/{requestId}, secret key
const s = event.smartSignals ?? {};
const clientMismatch = s.tlsFingerprint?.result;  // JA4 looks like an automation client
const relayed = s.proxy?.result || s.residentialProxy?.result;
const manyAccounts = event.accountsOnDevice.count >= 2;

if (event.decision === 'block' || (relayed && (clientMismatch || manyAccounts))) return deny();
if (relayed || clientMismatch) return challenge();  // proof-of-work, not a ban

Note what is absent: no IP deny list. The IP feeds the decision as context, never as the thing you block.

Responses that spare real phone users

Because carrier traffic is mostly legitimate, the response to “mobile IP plus weak signals” should be friction, not refusal. A proof-of-work challenge through prynt.challenge() costs a real phone a moment and costs a farm CPU on every attempt. Save hard blocks for strong device-level evidence: automation, tampering, many accounts on one device.

The VPN and proxy detection page summarizes the network signals, and the network page explains the opt-in reputation network, where a device confirmed bad elsewhere is flagged when it reaches you. When the IP can be anyone, identify the device instead.