What a New York City Mobile IP Looks Like to a Website

People ask us this on Telegram every week in some form: if I connect through one of your New York lines, what does the site on the other end actually see? Not the marketing answer, the technical one. Here it is. We run modems and phones on Verizon, AT&T and T-Mobile SIMs in Brooklyn, Queens and Manhattan, and we have spent a lot of hours looking at our own lines from the outside. This article walks through every field a site can read, in the order a fraud or geo system usually reads it.

Field one: the address and its owner

The first thing any server has is the source address of the connection. A lookup on that address returns the autonomous system that announces it. For our lines that is AT&T Mobility (AS20057), T-Mobile USA (AS21928) or Verizon Wireless, which shows up as Cellco Partnership on AS6167 or AS22394 depending on the block. There is no hosting company, no VPN provider and no data-center name anywhere in that record, because the SIM is a plain consumer SIM and the carrier treats it like one.

Address ownership is the single strongest signal a site has. Residential cable blocks are owned by cable companies, cloud blocks by cloud companies, and these are owned by the three US wireless carriers. A site that keeps a list of risky networks will not have a carrier's consumer block on it, because blocking it would lock out millions of phones.

Field two: the city, and why the borough never shows

Next comes geolocation. Commercial databases map carrier blocks to the metro where the carrier's packet gateway hands traffic to the internet. For the New York pools that comes back as New York, New York, Eastern time, sometimes with a ZIP centroid in Manhattan or Queens that has nothing to do with where the device is. Every one of our lines, whether the modem is in a Bushwick closet or a Midtown office, reads as New York City.

We want to be plain about this because other sellers are not: no website can tell Brooklyn from Manhattan from Jamaica, Queens by looking at an IP. The borough is where our hardware physically sits. It matters for signal, for which carrier is strongest, and for the honesty of saying the line is really in the city. It does not change what the geolocation field says, and it cannot. If someone promises a borough-level IP, they are describing a street address the database does not contain.

Field three: connection type and the NAT share

The better fraud tools try to classify the connection: cable, fiber, DSL, mobile, hosting, VPN. For a carrier block the answer is mobile or cellular, and the usual label is something like carrier-grade NAT. That label means the address is shared. At any moment the same public address is in use by other Verizon or AT&T subscribers in the region, people on the subway checking email, delivery drivers, someone's kid on a tablet.

This is the part customers sometimes get backwards. The sharing is the feature, not the flaw. A site cannot ban that address without banning the ordinary subscribers behind it, so it does not. What you hold exclusively is the SIM and the device, not the public address. Nobody else is sending traffic through your modem, and the behaviour the site attributes to the session is yours alone.

Field four: everything that is not the IP

Once the address checks out, the site moves on to signals that have nothing to do with us: the browser or app fingerprint, the time zone your system reports, the language, the account's age and history, and how the session behaves. A New York carrier address with a browser set to Central European time and a keyboard in Russian is a mismatch the IP cannot fix. Set the clock to Eastern, the locale to en-US, and act like a person at a normal pace.

For apps the picture is similar. A real Android phone on one of our lines presents a real device model, a real carrier name in the system status, and a network type of LTE or 5G. A desktop browser through the same line presents a desktop, which is fine for most jobs, but if the job is testing how an app behaves on a New York carrier network, the phone plan is the honest tool.

• Address owner: a US wireless carrier, nothing else
• Location: New York, NY, Eastern time, metro-level only
• Connection: mobile, behind carrier NAT, shared with real subscribers
• Your side: fingerprint, locale, account history, pace

What changes when you rotate

When you pull a new address from the dashboard, the rotation link, a timer or the API, the modem drops its carrier session and brings it back up. The carrier assigns another address from the same regional pool. The owner field stays the same carrier, the city stays New York, the connection type stays mobile. From the site's point of view a phone just moved cells or woke up from sleep, which happens all day long on every network in the city.

Because the pool is regional and finite, you will eventually see an address you had before. That is normal and it looks normal, since real phones cycle through the same pool. If you leave the session alone, the address is sticky for as long as the carrier keeps it, which on our New York lines is usually hours and sometimes a full day.

How to see all of this yourself

Take an hourly test, two dollars for the first two hours on 4G, and point curl at a what-is-my-ip service through the proxy. Then run the address through any public ASN lookup and a geolocation lookup. You will see the carrier, the city and the mobile label. Run it again after a rotation and compare. Do this before you build anything on the line, so you know exactly what the other side knows.

Frequently asked