Where Your Dedicated Modem Sits vs Where GeoIP Puts It

When you rent a dedicated mobile proxy from us you are renting a physical thing: one modem, router or phone, with one carrier SIM, in one rack, in one of eight US cities. Because the device is so concrete, buyers reasonably expect its IP address to point back to that rack. Then a geolocation lookup names a neighbouring metro, or only the state, and the obvious suspicion is that the device is not where we said. This article explains why a dedicated modem and its public address can disagree about location, why that disagreement is not a sign of sharing or relabelling, and what to do when the reading matters for the accounts you run on the line.

Private hardware, public front door

Dedicated describes the device and the SIM. Nobody else sends traffic through your modem. What dedicated cannot describe is the carrier's own network beyond the antenna, because no customer of any provider owns that part.

Your modem attaches to cell towers near our rack. From the tower, its traffic rides the carrier's internal network to a regional packet gateway, and only there does it meet the public internet. Carrier-grade NAT sits at that gateway, which means the public address your sessions show is drawn from a pool that ordinary subscribers in the region are also using. Your modem is yours alone; the front door it walks out of belongs to the carrier and serves a whole area. That front door is what the rest of the internet sees, and it is what location lookups try to place.

How a location lookup forms its answer

No IP address contains a position. Sites that show you a city are quoting a geolocation vendor, most often MaxMind GeoIP2, IP2Location, ipinfo or DB-IP. Those vendors assemble their maps from carrier registration records for each block, from where the block is announced in routing, from geofeeds that networks publish under RFC 8805, from latency measurements, and from location signals contributed by apps and devices.

For cellular blocks, those inputs describe the gateway region, not the tower and certainly not the rack. The usual result is the metro the gateway serves. Sometimes the vendor only commits to the state. Sometimes it names a nearby hub city where the carrier concentrates traffic for a wider area. What it will not do is pinpoint a block, a postal code or a district. Any seller of mobile proxies who promises that level of precision is promising something the databases do not hold.

The Boston rack: one room, two readings

We see this plainly in our own Boston racks. Verizon modems and AT&T modems there share the room, the power and the nearby towers. Look up a Verizon address from that site and the vendors say Boston. Query an AT&T modem in that room instead and the answer comes back New York.

The reason is network design, not hardware. Verizon exits that traffic in a way the vendors associate with Boston. AT&T carries New England sessions toward a hub that the vendors associate with New York, and registers the pool accordingly. Two dedicated modems a few feet apart can therefore report different cities, each consistently, with neither one shared or mislabelled.

For account work, consistency beats the label

Many of our customers keep one account per modem for months. For that kind of work, the exact city a vendor prints matters less than whether the story stays the same from login to login. A platform that sees an account in the New York metro every day is untroubled. A platform that sees it jump between regions, or between a US address and a foreign timezone, has something to ask about. Platforms are relaxed about a mobile address wandering within one carrier network; that looks like a person who took a flight to another state. What they do flag is one account, or one browser fingerprint, showing up in two places at the same moment. So never run the same login on two modems at once.

Two things can move the reading without anyone touching your device. Vendors refresh their databases on different schedules and do not always agree with one another. Carriers also shift address ranges between markets, so a fresh address after a rotation may be filed under a slightly different place than the last one. Neither is a fault in the modem. Both are reasons to check, rather than assume, before you attach a valuable account to a line.

Signals that travel with the browser, not the modem

The address is one input among several. Sites also read the timezone your system reports, the languages your browser lists, the HTML5 geolocation API, which answers from device GPS or nearby Wi-Fi rather than from any IP, and WebRTC, which can expose addresses if it is not handled. A US carrier address next to a browser clock set to another continent is a contradiction a careful site will notice.

If each modem backs a profile in GoLogin or Undetectable.io, let the profile take its timezone and geolocation from the proxy address. That keeps the device, the address and the browser telling one consistent story, which is the whole point of paying for hardware nobody else touches.

Checking and correcting your modem's reading

Treat geolocation as something you verify when a line is delivered and again after anything changes.

• Settle on what the work needs: a particular metro, or simply a US state and country.
• Once the line is delivered, look it up with the free checker on this site's Tools page, then with two other vendors.
• Judge by where the answers cluster, not by the one that disagrees.
• Repeat after rotations and every so often on long-lived lines.
• If the reading is wrong for the job, tell support. Moving your dedicated line to another city or carrier is free. You can trigger the location move yourself from the dashboard, or let our team pick the carrier whose addresses are known to land where your work needs them.

Frequently asked