IPQualityScore Results for US Mobile IPs

IPQualityScore, usually shortened to IPQS, is one of the reputation services that checkout pages, sign-up forms and ad networks query before they decide how much friction to put in front of a visitor. If you run a SpoofProxies line, sooner or later someone on your team will paste its address into the IPQS lookup and ask what the number means. This page walks through the fields IPQS returns for an AT&T, T-Mobile or Verizon address, why a carrier IP tends to read the way it does, and where the score stops being useful. The goal is understanding the verdict, not gaming it.

The fields that matter on a carrier address

An IPQS lookup returns far more than a single number. For a mobile line the useful parts are the fraud score, the proxy, VPN and Tor booleans, a connection type field, the ISP and ASN, a mobile flag, a recent abuse flag, and a bot status flag. Each one is a separate judgement. The fraud score is a blend that IPQS computes from the others plus its own history of the address, and different customers of IPQS can request it at different strictness levels, which is why the same address can look calmer on the public lookup page than inside a merchant's risk dashboard.

On one of our lines you would normally expect the ISP to read as the carrier, the connection type to read as mobile, and the ASN to belong to the carrier's wireless network rather than to a hosting company. Those three facts are simply true: the SIM sits in a real modem, router or phone on a US carrier network, and the address is handed out by that carrier.

Why the proxy flag can still appear

People are sometimes surprised to see the proxy field set on a genuine mobile address. The reason is carrier-grade NAT. Every carrier in the US puts many subscribers behind a shared pool of public addresses, and the address you hold at a given moment is also, at other moments, the address of ordinary phones in the same region. IPQS learns from traffic it observes across its customers. If any device that has ever surfaced on that pool address relayed proxy traffic, or if the address has shown up in a honeypot, the flag can stick to it for a while.

That flag describes the address, not your line. Blocking a carrier address outright would lock out real customers who share it, so most integrations weigh the mobile connection type heavily and move on to behaviour, device and account signals.

Reading the fraud score without over-reading it

The fraud score runs from zero to one hundred, and IPQS documents its own risk bands in its developer docs. Treat those bands as the vendor's opinion, not a law of the internet. A merchant can set its own cut-off, can ignore the score for mobile traffic, or can combine it with email and device checks. So a middling score on a lookup page tells you very little about whether a specific site will challenge you. What moves the score on a carrier address is mostly the recent abuse history of that pool address and the strictness level of the query.

Because our lines rotate inside the carrier's regional pool, two lookups an hour apart may land on different addresses with different histories. If one address reads poorly, rotating and checking again is a fair diagnostic step. It is not a way to launder bad behaviour: if a platform has already decided an account is abusive, a new address changes nothing about the account.

What IPQS cannot see

IPQS scores the network endpoint. It does not see your browser fingerprint unless the site also runs its device script, it does not know whether your time zone matches the address, and it cannot tell how many different people share a CGNAT address right now. It also cannot tell whether the address belongs to a proxy customer or a commuter on a train. When a site treats you roughly despite a clean-looking IPQS result, the cause is usually elsewhere: cookies carried over from another location, a browser time zone set to a different continent, or automation that moves faster than a person.

A sensible routine for teams

Check a line once when you first set it up, note the ISP, connection type and ASN, and keep that as your baseline. Recheck only when something changes, such as after a location move between metros or when a platform starts behaving differently. Constant rechecking wastes lookups and teaches you nothing, because the pool will always contain some addresses with a history. For monitoring or QA work where you rotate often, sample a few addresses at the start of the day instead of scoring every one. Our plans include unlimited data and unlimited rotations, so a few diagnostic rotations cost nothing extra.

Setting up a IPQualityScore proxy on SpoofProxies

1. Add a line in the SpoofProxies dashboard in the metro you need and note the carrier assigned.
2. Copy the host, port, username and password and set them in a clean browser profile.
3. Run that address through the IPQS lookup and record ISP, connection type, ASN and the proxy flags.
4. If a single address reads poorly, rotate once and look again to see whether it was the pool address or the setup.
5. Keep the baseline and recheck only after a location move or a change in platform behaviour.

IPQualityScore proxy questions