A Shared Carrier IP Is Not Anonymity: What Pools Do for Trust

A common sales line for mobile proxies goes like this: your address is shared with many ordinary phones, so you blend into the crowd. The sharing part is true. Behind carrier grade NAT one public IPv4 fronts a large number of handsets in the same region at the same time. The second half is a misunderstanding of how platforms make decisions. Nobody at a social network or a retailer is trying to pick you out of a crowd by IP. They attribute by account, by device, and by behaviour, and the address is one signal among many. This page separates what a shared carrier address does for you from what it cannot, explains where trust on a mobile line really comes from, and shows why pool depth is an asset to manage rather than a place to hide.

What a carrier address is, precisely

Every one of our proxies is a single modem or phone with its own physical SIM, in a rack we operate in one of eight US metros. When that SIM attaches to AT&T, T-Mobile, or Verizon, the carrier's packet gateway for that region assigns a public address from a pool it manages for that gateway and APN. The pool is finite, and it belongs to that carrier in that place. A Verizon line in Chicago and a Verizon line in Houston draw from different pools, and neither has anything to do with a T-Mobile line in the same building.

Because the carrier is running CGNAT, that public address is not yours alone. It is in front of many subscribers at once, and when your session detaches, the address returns to the free list and may front a different set of phones a moment later. The device is dedicated to you. The address is not, and no honest provider will tell you otherwise.

What sharing does for you, and what it does not

Sharing has one large, concrete benefit: it makes blocking the address expensive for the platform. Any rule that blocks a carrier IP outright also blocks the ordinary customers behind it, and a platform that does that at scale loses real users and generates support tickets. So platforms tend not to ban carrier ranges at the IP level. They tolerate the address and look elsewhere for the signal that matters. That is why a carrier address that shows a high number on a fraud checker still logs in cleanly on the platforms people care about.

What sharing does not do is make your session indistinguishable from the phones beside it. The platform sees your account, your cookies, your browser or app fingerprint, your timing, the sequence of actions you take, and the history attached to all of those. None of that is shared with the phones on the same address. If two of your identities run on the same device profile with the same habits, they look linked whether they share an address with five hundred strangers or with nobody at all.

Where trust on a mobile line actually comes from

Trust is a stack, and the address is the bottom layer, not the whole thing. The parts that carry weight are the ones a real phone user produces without trying.

• A carrier ASN: the address belongs to AT&T, T-Mobile, or Verizon, and platforms treat that origin as a normal consumer source
• Consistent geography per account: the address geolocates where the account claims to live, session after session
• Clean separation: each identity, or small group of related identities, has its own line, device profile, and address history
• Sensible rotation: a cadence that resembles a phone moving through its day, not a timer firing every few seconds
• Behaviour that fits: request rates, dwell times, and action sequences that a person could plausibly produce

Geography is part of the address, and it is fixed by the gateway

One detail worth knowing before you choose a metro: the location a platform reads from a mobile address is the location of the carrier gateway that issued it, not the physical rack. Most of the time those agree. Occasionally they do not. Our Boston hardware is a clean example: its Verizon addresses geolocate as Boston, while its AT&T addresses geolocate as New York, because that is where AT&T's gateway for the region sits. Neither is wrong, but an account that claims to be in Boston should be on the Verizon line there, not the AT&T one.

The practical rule is to check where a line's addresses resolve before you attach an account to it, and then keep that account on lines that resolve the same way. An account whose address jumps between metros week to week has a geography problem that no amount of sharing solves. Consistency is the signal, and consistency is something you control by choosing the line, not by hoping the pool hides you.

Pool depth as an asset, not a hiding place

Providers like to advertise pools of millions of addresses. That figure describes a whole carrier's inventory across the country. The only part of it you ever touch is the share exposed to your own line's carrier and metro, and that share is finite and reused. What you actually buy is per-line depth: how many distinct addresses a single line turns up over time. As a rule of thumb, one carrier line rotated many times a day shows a few hundred distinct addresses in a week and low thousands over a quarter, with the discovery rate fastest in the first days and slowing afterwards without ever fully stopping. The honest exact figure depends on the carrier, the metro, and your cadence.

Depth matters for trust in a specific way. It is what lets you give each identity its own address history instead of stacking a dozen accounts on the same few addresses, and it is what lets a fresh onboarding flow start from an address your other accounts have not recently used. Two things move independently here: long-run depth, meaning how many fresh addresses the line yields over weeks, and short-term freshness, meaning how often a rotation lands on an address the line held in the last day. A line can be deep but repetitive, or shallow but rarely repeating. Compare lines by yield per rotation, not by any headline count.

Rotation is a signal too

Rotating more does not manufacture addresses. Rotating every two minutes on a shallow block produces a long list of rotations and a short list of distinct addresses, most of them revisited, and an account that hops between the same six addresses all day looks less like a phone than one that sits still. On a lightly loaded pool a brief detach often returns the same address, because nobody claimed it while you were offline. That is not a fault. For an aged account it is the best possible behaviour: a stable home on a carrier ASN with a consistent location.

When you do need a fresh address, for verification, new-account onboarding, or research, rotate and read the result. If it repeats, rotate again or ask support to lengthen the detach so the pool has time to reassign it. If repeats are frequent and freshness is the point of the job, the lever is carrier and city, not the timer. In our racks Verizon lines tend to hand out a fresh address readily, AT&T lines tend to be stickier and revisit addresses more often, and T-Mobile varies a lot by metro. Support can say which line in a given city is currently rotating freshest.

Putting it together with SpoofProxies

Give long-lived accounts a sticky line and leave it alone. Give verification and onboarding work a line whose carrier and metro yield fresh addresses, and rotate between tasks. Keep identities apart at the device and behaviour layer, because that is where linking happens. Most operators end up with a small mix: one or two stable lines and one that churns.

Then test against the real target rather than a checker. Log in, act normally, and watch for friction. If the address behaviour does not match the job, open live chat and tell us what you are running and where. We can switch the carrier, move the port to another metro, or adjust the detach duration, and all of it is free. What we will not do is claim that any address makes you invisible, because none does, and the trust you are looking for is built on the layers above it.

Frequently asked