Reading a Mobile IP's Fraud Score From Code

Paste the exit IP of a mobile line into an IP reputation checker and you will often see a fraud score in the middle or upper range next to the words mobile and proxy. Developers see that and assume the line is burnt. It usually is not. This page explains what the number is made of, shows how to read a scoring API from code so you can log the result against each rotation, and lists the fields that predict real-world behaviour better than the headline score. The examples use a generic scoring API shape; adapt the field names to the service you use.

What is behind the number

Carriers put many subscribers behind each public IPv4 address with carrier-grade NAT. One address on T-Mobile or Verizon can front hundreds of handsets at once. Reputation services see traffic from all of them: shopping, logins, ad clicks, and whatever a few bad actors are doing. The score is an aggregate over that crowd. It is not a statement about your device or your traffic.

A second input is classification. Services flag the address as mobile and often as a proxy or VPN because carrier ranges are known to be used by mobile proxy providers. That flag raises the score mechanically. A datacenter address with no history can show a lower number while being blocked outright by the same sites that welcome the carrier address.

What a destination actually does with it

Large sites do not block on a third-party score. They combine the IP's class (mobile, residential, hosting), the ASN, device signals and behaviour. A mobile class address gets lenient treatment because blocking it would block real customers on the same NAT. That is the practical value of a carrier line and it does not show up in a single number.

Where the score does matter: some smaller sites and some fraud vendors do use a threshold. If a target does, test it empirically with your own flows rather than guessing from the checker. A line that passes your target's signup and checkout is a good line regardless of what a checker prints.

Querying a scoring service from a script

Most services offer a GET with the IP in the path or query and a key in a header or parameter, returning JSON. Read the exit IP from GET /proxy/status, then query the scorer with the IP. Log the full response, not just the score, keyed by licence uuid and timestamp.

Do not query the scorer through the line. Query it directly from your server. The scorer should see your server asking about an address, not the address asking about itself; the latter can be recorded as a probe and affect the very score you are reading.

import os, requests
BASE = "https://cp.mobileproxiesus.com/backend/api_v1"
H = {"x-api-key": os.environ["MPUS_API_KEY"]}
SCORER = "https://scoring.example/v1/ip/{ip}"   # placeholder; use your vendor's
lines = requests.get(f"{BASE}/proxies/my", headers=H, timeout=15).json()["proxyList"]
line = next(l for l in lines if l["uuid"] == UUID)
ip = requests.get(f"{BASE}/proxy/status", params={"license": UUID}, timeout=15).json()["ip"]
r = requests.get(SCORER.format(ip=ip), headers={"X-Api-Key": os.environ["SCORER_KEY"]}, timeout=10).json()
row = {
  "line": line["uuid"], "ip": ip, "carrier": line["carrier"], "city": line["city"],
  "score": r.get("fraud_score"), "is_mobile": r.get("mobile"), "is_proxy": r.get("proxy"),
  "asn": r.get("asn"), "recent_abuse": r.get("recent_abuse"), "connection": r.get("connection_type")
}
print(row)

Fields that predict more than the score

Connection type: should read mobile or cellular. ASN: AS20057 for AT&T, AS21928 for T-Mobile, AS22394 (sometimes AS6167) for Verizon. If a service shows a hosting ASN for a supposed mobile line, that is a real problem; a high score with the right ASN and type is not.

Recent abuse: a boolean or a timestamp saying the address was seen in abuse reports in the last days. This one is worth acting on: if true, rotate and re-check. Proxy or VPN flag: expect it to be set sometimes; it reflects the range, not your line. Bot activity: same, crowd-derived. Treat these as context in a log, not as gates in a pipeline.

Tracking the score across rotations

Because every rotation hands you another address from the same regional pool, scores vary from one rotation to the next. Logging the score per rotation over a day gives a distribution for that carrier and metro. Use it to set an informed policy: for example, rotate once more if recent_abuse is true, otherwise proceed regardless of score.

Keep a simple table: timestamp, licence uuid, exit IP, score, abuse flag, outcome of the job that ran on it. After a week you will know whether score correlates with outcomes on your targets. For most targets it does not, and the table lets you prove it to the person who keeps asking.

# rotate, read the new exit IP, score it, append to a CSV
for _ in range(10):
    ip = rotate_and_wait(line)                 # from the API article
    s = score(ip)                              # your scorer wrapper
    log.writerow([now_utc(), line["uuid"], ip, s["fraud_score"], s["recent_abuse"]])
    time.sleep(max(line["min_time_change_ip"], 2) * 60)

Reading checkers honestly

A high number on a shared carrier address is the normal state of the internet's mobile edge. A perfect zero on a mobile address is rarer and usually means the service has little data on that range, not that the range is clean. The useful question is whether the address is classified as what it is (mobile, carrier ASN, US) and whether anything recent is attached to it.

If a specific target blocks a line, rotate and test again before concluding anything. If it blocks three addresses from the same carrier in the same metro, the target has a policy against that range; move the line to another metro, which is free within the plan. The host and ports can change on a move, so re-read GET /proxies/my afterwards.

Frequently asked