DEV Community: IP99

This Week's Proxy Exits: 10.9M New Addresses, Still Almost All Off Datacenter Space

IP99 — Fri, 30 Oct 2026 13:19:06 +0000

Datacenter blocklists are still the default proxy defence in a lot of fraud stacks. The addresses showing up in proxy supply this week mostly were not in datacenters.

Between 23–29 October 2026 (UTC), the IP99 risk feed captured 10,930,592 proxy exit addresses it had not seen in the previous 7 days (−4% vs the prior week). Source page: ip99.com/en/proxy-exits (generated 30 Oct 2026 UTC).

What those addresses sit on

Usage type	Addresses	Share
Residential broadband	8,701,207	79.6%
Mobile network	1,425,387	13.0%
Gateway / NAT egress	488,101	4.5%
Datacenter	240,834	2.2%
Education network	47,096	0.4%
Unclassified	27,967	0.3%

About 62% were rated high-risk at the moment of capture. The rest still carried a proxy-class signal at a lower risk level.

IP99 counts an address as "captured" when it enters the feed with a proxy-class signal (proxy, VPN, dial-up pool, cloud phone, or hijacked shared proxy) and was not in the live 7-day risk mirror. Addresses that go quiet and return can be counted again. The page describes what 68 upstream collection sources delivered — not the total number of proxies in the world. No address lists are published.

Why the 2% matters

If your defence is mainly an ASN or hosting blocklist, you are mostly looking at that 2.2% datacenter slice. Residential and mobile space is where home-broadband proxies and dial-up pools live. An address that keeps turning up in proxy supply is a proxy exit whatever its ISP label says.

That is the same reason a residential allowlist fails the other way: usage type answers "what kind of network is this," not "is this address currently sold as an exit." Rotating residential proxies and dial-up pools are designed to sit in DYN / MOB space. Detecting them needs supply-side observation with an age attached, not a permanent network-type label.

Which networks show up most

Top ASNs in this week's capture window (by distinct address count):

ASN	Addresses	Share
AS4134	1,018,153	9.3%
AS4837	748,461	6.8%
AS9808	370,984	3.4%
AS6057	261,568	2.4%
AS36947	209,880	1.9%

Large access networks appearing here are a clue about where proxy supply is being sold from — not a claim that every customer on those networks is a proxy. Ban a whole ASN and you take out legitimate home and mobile users. Prefer per-address evidence at decision time.

Day-to-day shape

Captured addresses (new to the prior 7-day mirror that day), with how many were high-risk at capture:

Day (UTC)	Captured	High-risk at capture
2026-10-23	1,785,796	1,147,796
2026-10-24	1,658,044	1,025,424
2026-10-25	1,570,214	957,858
2026-10-26	1,506,506	921,527
2026-10-27	1,496,376	927,608
2026-10-28	1,482,695	919,210
2026-10-29	1,430,961	917,972

Volume eased week-over-week (−4% after last week's rebound to 11.5M), while upstream sources rose from 54 to 68. More sources did not mean a bigger headline total — the soft dip is about what those collectors delivered into the 7-day mirror, not a claim that proxy supply worldwide shrank. The mix held: residential near 80%, datacenter still about 2%. Daily capture drifted gently lower through the window, staying in a band roughly 1.4–1.8M addresses — no single spike day that would make a static list look "caught up."

How to use this without over-blocking

Branch on evidence, not network type. Residential is where your customers live; do not hard-block on DYN / MOB alone.
Step up, don't stop. A fresh proxy-class signal on signup, a coupon claim, or a login from a new device justifies a second factor or a delay — not an immediate ban.
Read the age. evidence_state: "stale" means the address was in supply before and is not now; treat it as a weak prior. Re-query at decision time rather than caching a verdict for days.
Keep the timestamp. Store computed_at with the decision so a disputed block can be traced back to when the observation was made.

Check one yourself

Free, no signup:

curl https://ip99.com/v1/ip/8.8.8.8

Look at evidence_state (active / stale / none), risk.score, and the proxy-class signals. A score of 0 is not "safe" — it means IP99 holds no current verifiable evidence against that address. The score is the freshness and strength of that evidence, not a probability that the address "is an attacker."

The same lookup is available to agents as an MCP tool at https://ip99.com/mcp (ip_risk_lookup). Field reference and routing notes live on the API docs.

Don't Rate-Limit Googlebot Like a Proxy Farm: Route Crawlers by IP Signal

IP99 — Thu, 29 Oct 2026 13:12:33 +0000

Your content and API edge sees two kinds of automation that look similar in the logs: search-engine crawlers you usually want indexed, and scrapers that rotate through proxy exits to drain pages, prices, or inventory. A single requests-per-IP throttle treats them the same. That is how you starve SEO while the farm simply dials a fresh residential address.

IP99 by ThreatHunter puts a typed signal on the free GET /v1/ip/{ip} response for the first case: crawler means search-engine crawler egress. Official docs treat it as benign — it does not participate in scoring and never becomes a scored piece of evidence. Proxy farms show up under different slugs (proxy, vpn, dialup_pool, cloud_phone, …) with a score that measures freshness and strength of verifiable evidence, not "probability this visitor is an attacker."

What you are actually sorting

Traffic	What you want	Naïve edge rule	Better branch
Googlebot / Bingbot / similar	Allow (or polite crawl budget)	Same QPS bucket as scrapers	Prefer allow / dedicated budget when `crawler` fires
Proxy-rotating scraper	Cap, challenge, or block	Rate limit one IP → farm switches	Branch on proxy-class signals + `evidence_state`
Corporate / CDN egress	Usually allow	Ban all `hosting`	`hosting` / `mobile` describe the network, not risk
Real user behind CGNAT	Allow	Ban shared IP → whole building	Prefer step-up over hard-ban

Official signal table (ten slugs): eight risk labels (proxy, vpn, dialup_pool, hijacked_proxy, osint, cloud_service, cloud_phone, plus crawler listed among them but benign), and two network attributes (hosting, mobile) that are not risk verdicts on their own. Google Public DNS (8.8.8.8) carries hosting with score 0 — a reminder that "datacenter space" ≠ "scraper."

From IP99's own content/API anti-crawl note: scrapers rotate exits across proxy pools; routing by risk type (and share scope when you have it) mis-fires less than pure frequency limits.

Triage order at the edge

evidence_state — can this conclusion be trusted now? active = fresh evidence still scoring; stale = seen before, aged out, score 0 (weak feature only); none = never seen (coverage gap), not "safe."
risk.signals — why it matches. If crawler is present, treat as known search egress: do not fold it into your "proxy farm" ban path. If proxy-class signals fire without crawler, that is the scrape / abuse path.
risk.score / risk.level — only after state. Official disposition guidance (generic, not a contract promise): 0 → do not stamp "clean"; 1–29 → log/observe; 30–69 → verify (CAPTCHA, second factor, rate limit, demote) rather than hard-ban; 70–100 → block when business cost allows.
Share scope — Pulse share_tier (T0–T3) if you have professional history; on free responses use usage_type (IDC vs DYN / MOB / GTW) as a rough prior before one ban equals one building.
degraded: true — discount the answer when sources are partial.

UA strings alone are not enough: scrapers forge Googlebot. Combine UA with egress identity (published bot prefixes where vendors publish them, plus an IP risk lookup). IP99's crawler tag is the supply-side observation that the address is search-crawler infrastructure — complementary to vendor prefix lists, not a replacement for verifying the ones you care about most.

Live curls (2026-10-29, no API key)

Anonymous quota: 500 lookups/day per client IP, 60/min. Sign in for 5,000/day. Overseas self-serve Pro / Pro+ buys volume, not a different score — official line: you pay for volume, not a better answer. Per-item evidence rows, share_tier, and ?at= history are a separate professional / contracted Pulse capability.

# Datacenter control: hosting attribute, score 0 — not a scraper by itself
curl https://ip99.com/v1/ip/8.8.8.8

# Docs demo residential address — mask the last octet in tickets/logs
curl https://ip99.com/v1/ip/27.22.66.200

# Remaining anon quota
curl https://ip99.com/v1/me

Sample A: hosting ≠ crawler ≠ proxy farm

Captured ~2026-10-29 13:08 UTC:

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-29T13:08:06Z",
  "evidence_state": "none",
  "geo": {
    "country": "US",
    "region": "California",
    "city": "Mountain View",
    "tz": "America/Los_Angeles"
  },
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["hosting"]
  }
}

usage_type: IDC plus hosting describes where the address lives. There is no crawler and no proxy-class signal. A rule that bans every IDC egress will also ban DNS resolvers, CI runners, and your monitoring probes.

Sample B: residential proxy churn (the scraper-shaped path)

Same window; last octet shown because this is IP99's documented demo address — still mask real customer IPs in your tickets:

{
  "ip": "27.22.66.200",
  "computed_at": "2026-10-29T13:08:32Z",
  "evidence_state": "active",
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Yicheng",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 8,
    "level": "low",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

This is residential broadband with dial-up-pool / proxy evidence — the rotating-exit pattern scrapers buy. Disposition differs from Googlebot: prefer verify / tighter crawl budget / delay expensive endpoints. hijacked_proxy still argues for careful appeals (the line owner may be a victim), not "delete the building forever."

When your edge does see crawler (often on known search infrastructure), route it to the allow / polite-crawl lane even if the same IP sits in hosting space. Do not let a global "block hosting" or "block anything with a risk slug" rule catch it.

A minimal edge hook

# Server-observed client IP only — never trust a body field
IP="$CLIENT_IP"
RESP=$(curl -sS "https://ip99.com/v1/ip/${IP}")

# Pseudocode:
# state = RESP.evidence_state
# signals = RESP.risk.signals or []
# if "crawler" in signals:
#     allow_or_polite_budget()
# elif state == "active" and any(s in signals for s in
#         ("proxy","vpn","dialup_pool","cloud_phone","cloud_service")):
#     if RESP.risk.score >= 70: challenge_or_block()
#     elif RESP.risk.score >= 30: captcha_or_slow()
#     else: observe()
# else:
#     normal_rate_limits()

Re-query at decision time. Do not cache a verdict across days: scores decay with evidence age, and evidence_state is how you tell "seen before, expired" from "never seen." Store computed_at with the decision if you may need to defend it later.

Context from this week's proxy exits

Between 22–28 October 2026 (UTC), the IP99 risk feed captured 11,196,585 proxy exit addresses it had not seen in the previous 7 days — about 80% residential broadband, datacenter only ~2.3%, from 68 upstream sources (proxy-exits). Most of the scrape supply you are fighting is not sitting in the ASN blocklist you already maintain. That is why signal-aware routing beats "ban hosting + rate-limit everyone else."

Try it

Free lookup (no key): ip99.com or curl https://ip99.com/v1/ip/8.8.8.8. Field reference: API docs. Agents can call the same verdict as MCP tool ip_risk_lookup at https://ip99.com/mcp.

Cloud Phones Look Like Real Mobiles: Catch Farms at the IP Layer

IP99 — Wed, 28 Oct 2026 13:15:43 +0000

Your signup funnel sees a "phone": WebView UA, touch events, maybe a real device fingerprint. The account farm on the other side is a rack of cloud phones — real or virtual handsets hosted in a datacenter, remoted into by operators who spin up hundreds of profiles a day.

Device-side checks often say "mobile." Network-type blocklists often say nothing useful: the egress sits in hosting space, or it sits behind whatever the vendor leased. What you need at registration, claim, or payout is an IP-layer signal that names the pattern, not a guess about the handset.

IP99 by ThreatHunter exposes that as cloud_phone on the free GET /v1/ip/{ip} response — one of ten typed signals — alongside evidence_state and a 0–100 score that measures freshness and strength of verifiable evidence, not "probability this person is an attacker."

What a cloud phone is (and is not)

Thing	What it is	What a naive rule sees
Real cellular user	Handset on a mobile ASN (`usage_type: MOB`)	Mobile UX + mobile network
Cloud phone farm	Handset (or emulator) in a rack, remoted for bulk signup / farming	Mobile UX; network often hosting or unrelated
Residential proxy	Home broadband resold as an exit	Residential ASN; no phone at all
Dial-up pool	ISP lines that redial for a new address	Residential space; churning egress

Official IP99 signal table: cloud_phone means a cloud phone (a phone device in a datacenter). It is a risk signal. Contrast mobile and hosting: those describe the network, not risk evidence — Google Public DNS carries hosting with score 0. Do not ban on hosting alone. Do not treat every MOB address as a farm.

Also leave crawler alone: search-engine exits are benign and do not participate in scoring. Cloud-phone farms are a different problem from Googlebot.

Why device signals are not enough

Farms buy the stack you already trust: real Android images, real WebViews, residential-looking fingerprints sold as a service. Your client SDK reports "phone." Your fraud model sees mobile-shaped behavior. The cheap tell that survives that arms race is often where the TCP session comes from and whether that egress has been observed as cloud-phone infrastructure.

That observation expires. An address used by a farm yesterday may be quiet today. IP99's product stance is a judgement that expires: scores decay with evidence age; evidence_state tells you whether anything fresh is still on the board.

Triage order (same as every other IP99 gate)

evidence_state — can this conclusion be trusted now? active = fresh evidence scoring; stale = seen before, aged out, score 0 (weak feature only); none = never seen (coverage gap), not "safe."
risk.score / risk.level — only after you read state. 0 with none is not a clean bill of health.
risk.signals — why it scored. cloud_phone is a stronger farm smell than bare hosting. hijacked_proxy still means the line owner is likely a victim — step up, don't hard-ban the household forever.
Share scope — Pulse share_tier (T0–T3) if you have professional history; on free responses use usage_type (IDC vs DYN / MOB) as a rough prior before you equate one ban with one building.
degraded: true — discount the answer when sources are partial.

Official disposition guidance (generic, not a contract promise): score 0 → do not stamp "clean"; 1–29 → log/observe; 30–69 → verify (CAPTCHA, second factor, rate limit, demote) rather than hard-ban; 70–100 → block only when business cost allows, and still respect share scope.

Live curls (2026-10-28, no API key)

Anonymous quota: 500 lookups/day per client IP, 60/min. Sign in for 5,000/day. Overseas self-serve Pro / Pro+ ($29 / $99) buys volume, not a different score — official line: you pay for volume, not a better answer. Per-item evidence rows, share_tier, and ?at= history are a separate professional / contracted Pulse capability.

# Datacenter control: hosting attribute, score 0 — not a farm by itself
curl https://ip99.com/v1/ip/8.8.8.8

# Docs demo residential address — mask the last octet in tickets/logs
curl https://ip99.com/v1/ip/27.22.66.200

# Remaining anon quota
curl https://ip99.com/v1/me

Sample A: hosting is not cloud_phone

Captured ~2026-10-28 13:10 UTC:

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-28T13:10:41Z",
  "evidence_state": "none",
  "geo": {
    "country": "US",
    "region": "California",
    "city": "Mountain View",
    "tz": "America/Los_Angeles"
  },
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["hosting"]
  }
}

usage_type: IDC plus hosting describes where the address lives. There is no cloud_phone here. A rule that bans every IDC egress will also ban DNS resolvers, CI runners, and your own monitoring.

Sample B: residential churn ≠ handset farm

Same window; last octet shown because this is IP99's documented demo address — still mask real customer IPs in your tickets:

{
  "ip": "27.22.66.200",
  "computed_at": "2026-10-28T13:10:44Z",
  "degraded": true,
  "evidence_state": "active",
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Yicheng",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 17,
    "level": "low",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

This is residential broadband with dial-up-pool / proxy evidence — the second-dial / shared-exit problem, not a rack of remoted phones. Disposition differs: hijacked_proxy argues for step-up and careful appeals, not "delete the building." When your gate does see cloud_phone (often with hosting-side attributes), treat it as a farm-shaped smell: challenge identity, tighten device binding, delay payout — still prefer verify-over-ban on medium scores unless your loss model says otherwise.

A minimal signup / claim hook

# At registration or high-value claim — server-observed client IP only
IP="$CLIENT_IP"   # from the reverse proxy, never from a JSON body field
RESP=$(curl -sS "https://ip99.com/v1/ip/${IP}")

# Pseudocode:
# state = RESP.evidence_state
# signals = RESP.risk.signals or []
# if state == "active" and "cloud_phone" in signals:
#     step_up(challenge="phone_otp_or_manual_review")
# elif state == "active" and RESP.risk.score >= 70:
#     decide_with_share_scope(...)
# elif state in ("stale", "none") and score == 0:
#     do_not_mark_clean(); continue_normal_friction()

Persist computed_at, evidence_state, score/level, and signals with the decision so chargeback week can replay what you knew — the free /v1/ip endpoint answers now only; historical ?at= needs Pulse.

What this article is not claiming

IP99 does not ship a Tor-specific signal; do not market one.
Risk score is not attacker probability.
Free /v1/ip and professional Pulse share one score for one IP; Pulse adds evidence detail and optional history, not a second verdict.
IP99 and ThreatHunter datasets are related products under the same company — do not claim they are identical feeds.
No invented accuracy rates, customers, or funding numbers appear above. Mask real residential or mobile subscriber IPs in anything you publish or paste into tickets.

Try it

Open ip99.com, paste an egress, and read risk.signals before you trust a "mobile" client claim. Or:

curl https://ip99.com/v1/ip/8.8.8.8

API shape, quotas, and field semantics: ip99.com/api. When cloud_phone shows up active on a signup that already looked like a handset, you finally have a name for the farm — and a score that will forget it when the evidence goes stale.

What Did We Know at Chargeback Time? Replaying IP Risk with a Timestamp

IP99 — Tue, 27 Oct 2026 13:16:11 +0000

A chargeback lands weeks after checkout. Your fraud queue opens the order, copies the billing IP, and hits today's IP reputation API. The score is 0. Someone stamps the dispute "clean egress" and moves on.

That workflow asks the wrong question. IP risk on IP99 by ThreatHunter is a judgement that expires: the score measures freshness and strength of verifiable evidence, not "probability this cardholder is an attacker." An address that looked like a dial-up proxy exit at purchase may show evidence_state: none and score 0 by the time Finance asks. Re-querying now does not reconstruct then.

Live gate vs chargeback clock

Moment	Question	Free `GET /v1/ip/{ip}`	Pulse `GET /pulse/v1/ip/{ip}?at=`
Checkout / claim	Is this egress risky right now?	Yes — no key required	Same score, more evidence detail
Chargeback / audit	What did we know at order time?	No — `at` returns 400 `at_unsupported`	Yes — professional tier + history enabled, ~30 days back

Official product split: basic endpoint for real-time control (sign-up, sign-in, pre-order); Pulse for after-the-fact review, reconciliation, and strategy back-testing. One IP, one score — Pulse is not a "better verdict," only a deeper and time-travel view of the same judgement.

What to store at decision time (so replay is possible)

If you only keep the final allow/deny bit, chargeback week has nothing to replay. At the gate that matters (checkout, claim, payout), persist at least:

Client egress IP (server-observed — never trust a body field the browser sent).
computed_at from the IP99 response (RFC 3339).
evidence_state, risk.score / risk.level, and risk.signals (or "signals absent").
network.asn and network.usage_type for blast-radius context when you lack Pulse share_tier.

That snapshot is your audit trail on the free tier. Historical ?at= later lets you re-ask the feed as of that moment; it does not replace logging what your gate actually used.

How to read a replay (same triage order)

Whether you look at the stored snapshot or a Pulse history response, official reading order still applies:

evidence_state — can this conclusion be trusted at that moment? none means never seen (coverage gap), not "safe." stale means seen before but evidence aged out (score 0, weak feature only).
risk.score / risk.level — only meaningful once state is active or stale.
risk.signals — why it scored: proxy, vpn, dialup_pool, cloud_phone, hijacked_proxy, … matter differently for dispute letters than bare hosting (a network property — Google Public DNS carries hosting with score 0).
Share scope — Pulse share_tier (T0–T3) if you ever blocked; on free responses use usage_type (DYN / MOB vs IDC) as a rough prior. Do not equate one residential NAT ban with one exclusive VPS ban.
Degraded marker — basic body degraded: true, or Pulse header X-Pulse-Degraded: 1 — discount the answer.

hijacked_proxy still means the line owner is likely a victim; a chargeback write-up that says "banned the household forever" is usually the wrong story even when proxy evidence was active at purchase.

Live curls (2026-10-27, no API key)

Anonymous quota: 500 lookups/day per client IP, 60/min. Sign in for 5,000/day. Overseas self-serve Pro / Pro+ buys volume only ($29 / $99) — same evidence fields on /v1/ip, not a better score. Per-item evidence, share_tier, and ?at= history are a separate professional / contracted Pulse capability.

# What the free API answers: now only
curl https://ip99.com/v1/ip/8.8.8.8

# Docs demo residential address — mask the last octet in tickets
curl https://ip99.com/v1/ip/27.22.66.200

# Remaining anon quota (does not spend a lookup on some setups; still cheap to check)
curl https://ip99.com/v1/me

# History needs Pulse + professional key — free /v1/ip rejects at=
# curl -H "X-API-Key: YOUR_KEY" \
#   "https://ip99.com/pulse/v1/ip/86.111.136.23?at=2026-09-14T09:29:23Z"

Sample A: datacenter control (score 0 is not a chargeback win)

Captured ~2026-10-27 13:13 UTC:

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-27T13:13:13Z",
  "evidence_state": "none",
  "geo": {
    "country": "US",
    "region": "California",
    "city": "Mountain View",
    "tz": "America/Los_Angeles"
  },
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["hosting"]
  }
}

hosting here is network shape, not proxy proof. evidence_state: none with score 0 means IP99 holds no current verifiable risk evidence — not that the payment was legitimate.

Sample B: residential dial-up / proxy supply (mask last octet)

Same day live lookup. Full address works in the curl above; tickets should show 27.22.66.x.

{
  "ip": "27.22.66.x",
  "computed_at": "2026-10-27T13:13:15Z",
  "evidence_state": "active",
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Nanzhang",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 18,
    "level": "low",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

Still DYN home broadband; signals say dial-up pool + proxy presence; hijacked_proxy warns collateral. active + low is friction territory at checkout — and the score will move as evidence ages. If you only re-check this IP at chargeback time without a stored computed_at, you may see a different story and wrongly conclude the gate was wrong.

Docs also show the same idea on Pulse history: one Luxembourg residential proxy exit scored 90 at a named past moment and 77 later — same address, same feed, evidence aged. That drift is intentional.

Minimal gate sketch (store the snapshot)

import json, urllib.request
from datetime import datetime, timezone

def lookup_now(ip: str) -> dict:
    req = urllib.request.Request(f"https://ip99.com/v1/ip/{ip}")
    with urllib.request.urlopen(req, timeout=5) as r:
        return json.load(r)

def snapshot_for_order(ip: str) -> dict:
    d = lookup_now(ip)
    return {
        "egress_ip": d["ip"],
        "computed_at": d["computed_at"],
        "evidence_state": d["evidence_state"],
        "score": d["risk"]["score"],
        "level": d["risk"]["level"],
        "signals": d["risk"].get("signals"),
        "asn": d.get("network", {}).get("asn"),
        "usage_type": d.get("network", {}).get("usage_type"),
        "stored_at": datetime.now(timezone.utc).isoformat(),
    }

# At chargeback: compare dispute narrative to snapshot_for_order(...).
# To re-ask the feed as of order time, use Pulse ?at= with a professional key —
# do not pretend free /v1/ip can time-travel.

CORS is open on /v1/ip, but run the gate on your server. Import https://ip99.com/openapi.json into Postman or codegen if you want a typed client. Agents can call the same live lookup as MCP tool ip_risk_lookup at https://ip99.com/mcp.

Honest limits

Score is not attacker probability; 0 / evidence_state: none is not "safe."
Free /v1/ip answers now. Passing at yields at_unsupported.
Pulse ?at= needs professional access and history enabled separately; history indexes IPv4 in the documented window (~30 days). Do not invent free historical fields.
IP99 and ThreatHunter branding: IP99 is the product; do not claim the free API and every ThreatHunter dataset are identical.
Mask the last octet of real residential or mobile addresses in public tickets and posts.

Try it

Paste a checkout egress into ip99.com or run the free curls above. For live gates, branch on evidence_state + typed signals and store computed_at with the order. For chargebacks, argue from that snapshot — and use Pulse history when you truly need "what did the feed say at purchase," not today's re-score of a recycled address.

This Week's Proxy Exits: 11.5M New Addresses, Still Almost All Off Datacenter Space

IP99 — Mon, 26 Oct 2026 13:17:45 +0000

Datacenter blocklists are still the default proxy defence in a lot of fraud stacks. The addresses showing up in proxy supply this week mostly were not in datacenters.

Between 19–25 October 2026 (UTC), the IP99 risk feed captured 11,525,472 proxy exit addresses it had not seen in the previous 7 days (+6% vs the prior week). Source page: ip99.com/en/proxy-exits (generated 26 Oct 2026 UTC).

What those addresses sit on

Usage type	Addresses	Share
Residential broadband	9,151,795	79.4%
Mobile network	1,503,531	13.0%
Gateway / NAT egress	526,366	4.6%
Datacenter	260,847	2.3%
Education network	49,677	0.4%
Unclassified	33,256	0.3%

About 64% were rated high-risk at the moment of capture. The rest still carried a proxy-class signal at a lower risk level.

IP99 counts an address as "captured" when it enters the feed with a proxy-class signal (proxy, VPN, dial-up pool, cloud phone, or hijacked shared proxy) and was not in the live 7-day risk mirror. Addresses that go quiet and return can be counted again. The page describes what 54 upstream collection sources delivered — not the total number of proxies in the world. No address lists are published.

Why the 2% matters

If your defence is mainly an ASN or hosting blocklist, you are mostly looking at that 2.3% datacenter slice. Residential and mobile space is where home-broadband proxies and dial-up pools live. An address that keeps turning up in proxy supply is a proxy exit whatever its ISP label says.

Which networks show up most

Top ASNs in this week's capture window (by distinct address count):

ASN	Addresses	Share
AS4134	998,961	8.7%
AS4837	725,984	6.3%
AS9808	367,102	3.2%
AS6057	269,928	2.3%
AS36947	242,659	2.1%

Day-to-day shape

Captured addresses (new to the prior 7-day mirror that day), with how many were high-risk at capture:

Day (UTC)	Captured	High-risk at capture
2026-10-19	1,638,525	1,098,049
2026-10-20	1,496,080	1,062,230
2026-10-21	1,679,859	1,061,464
2026-10-22	1,696,954	1,060,504
2026-10-23	1,785,796	1,147,796
2026-10-24	1,658,044	1,025,424
2026-10-25	1,570,214	957,858

Volume rebounded week-over-week (+6% after last week's soft dip), and the mix held: residential near 79%, datacenter still about 2%. Daily capture stayed in a band roughly 1.5–1.8M addresses — no single spike day that would make a static list look "caught up."

How to use this without over-blocking

Branch on evidence, not network type. Residential is where your customers live; do not hard-block on DYN / MOB alone.
Step up, don't stop. A fresh proxy-class signal on signup, a coupon claim, or a login from a new device justifies a second factor or a delay — not an immediate ban.
Read the age. evidence_state: "stale" means the address was in supply before and is not now; treat it as a weak prior. Re-query at decision time rather than caching a verdict for days.
Keep the timestamp. Store computed_at with the decision so a disputed block can be traced back to when the observation was made.

Check one yourself

Free, no signup:

curl https://ip99.com/v1/ip/8.8.8.8

The same lookup is available to agents as an MCP tool at https://ip99.com/mcp (ip_risk_lookup). Field reference and routing notes live on the API docs.

Stop Coupon Farms Without Banning a Building: IP Risk at Claim Time

IP99 — Sun, 25 Oct 2026 13:15:21 +0000

Yesterday’s playbook for bulk signup still applies when the prize moves downstream: new-user coupons, referral bonuses, and first-order subsidies. Promo farms rarely need a datacenter flood. They rotate residential or dial-up exits, sometimes through cloud phones, claim once per identity surface, and leave. A static “block all hosting” rule misses most of that traffic; a hard ban on every flagged address can still take out a whole building on shared broadband.

IP99 by ThreatHunter gives you a free GET /v1/ip/{ip} answer you can call at claim time: typed signals (proxy, dialup_pool, cloud_phone, …), evidence_state, and a 0–100 score that measures freshness and strength of verifiable evidence — not “probability this shopper is an attacker.”

Why claim time is a different gate than signup

Signup gates care about account inventory. Promo gates care about burn rate on a finite budget. The same egress pattern shows up for both, but the cost of a false hard-ban is different: locking out a CGNAT neighborhood during a flash sale can spike support tickets and kill conversion faster than a delayed coupon.

Typical claim-side patterns:

Pattern	Signals you often see	What a naive rule does wrong
Rotating residential / dial-up pool	`proxy` + often `dialup_pool` on `usage_type: DYN`	“Allow residential” lets the farm through
Cloud phone farm	`cloud_phone` (often with hosting attributes)	Looks like a handset in the UX; network-type rules miss it
Hijacked home exit	`hijacked_proxy`	Banning the IP punishes the line owner, not the farm
Classic VPS / VPN	`proxy` / `vpn` + `IDC`	Network-type blocklists catch only this row

If your coupon service only asks “is this IDC?”, you are still fighting last decade’s inventory. Weekly public aggregates on proxy exits keep showing that newly captured proxy-class addresses are overwhelmingly off datacenter space — so residential allowlists are not a promo shield.

A claim-time triage (step up, don’t flatten the building)

Official reading order on IP99 is still: evidence_state → score/level → which signals → (only if you ever ban) share scope. On the free API you do not get Pulse share_tier; usage_type plus evidence_state is enough for a coupon funnel:

evidence_state: none — no current evidence. Do not mark the claim “safe.” Keep normal fraud checks (device, payment, velocity).
stale — seen before, evidence aged out, score 0. Weak feature only; do not deny the coupon alone.
active + low (1–29) — log, optional soft friction (email confirm, slower claim, cap per ASN//24 for the campaign hour).
active + medium (30–69) — step up before payout: captcha, second factor, delay grant, or hold the reward for manual/risk review — prefer verify over IP ban when usage_type is DYN or MOB.
active + high (70–100) — decide by campaign burn. Still prefer challenge + delay on shared residential/mobile egress. If hijacked_proxy is present, treat the household as likely collateral: challenge the session, do not permanently ban the address for a promo.

Signal choice matters for how you step up: cloud_phone and dialup_pool are stronger promo smells than bare hosting (a network attribute — Google Public DNS carries hosting with score 0). crawler is benign and does not participate in scoring; do not treat search-engine exits like coupon farms.

Live curls (2026-10-25, no API key)

Anonymous quota is 500 lookups/day per client IP (60/min). Sign in for 5,000/day. Overseas self-serve Pro / Pro+ buys volume only ($29 / $99) — same evidence fields, not a “better score.” Professional evidence detail and ?at= history are a separate contracted tier.

# Egress you are about to claim from
curl https://ip99.com/v1/ip

# Public demo address often used in IP99 docs (mask last octet in tickets)
curl https://ip99.com/v1/ip/27.22.66.200

# Datacenter control: hosting attribute, score 0 — not a promo farm by itself
curl https://ip99.com/v1/ip/8.8.8.8

# Remaining anon quota
curl https://ip99.com/v1/me

Sample: residential dial-up / proxy supply (mask last octet)

Captured ~2026-10-25 13:12 UTC. Full address works in the curl above.

{
  "ip": "27.22.66.x",
  "computed_at": "2026-10-25T13:12:11Z",
  "evidence_state": "active",
  "degraded": true,
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Nanzhang",
    "admin_code": "420624",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 20,
    "level": "low",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

Read left to right: still DYN home broadband; signals say dial-up pool + proxy presence; hijacked_proxy warns the line owner may be a victim; evidence_state: active with a low score means friction at claim time, not a permanent ban. degraded: true means part of the feed was unavailable — treat the answer as soft. Scores move as evidence ages; the same IP an hour later can look different on purpose.

Sample: hosting control

{
  "ip": "8.8.8.8",
  "evidence_state": "none",
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

hosting alone is not a reason to deny a coupon. Pair typed proxy-class signals with campaign velocity and payment risk.

Wire it where the budget burns

Call the lookup on your server with the client’s real egress (reverse proxies lie if you only trust X-Forwarded-For without a trusted hop list). CORS is open on /v1/ip, but clients can forge their IP — keep the gate server-side.

Minimal shape for a claim endpoint:

Resolve public client IP.
GET https://ip99.com/v1/ip/{ip} (optional X-API-Key when you outgrow anon).
Branch on evidence_state then risk.level / risk.signals as above.
Persist computed_at, score, signals, and your decision for dispute review later.

Free /v1/ip answers now. “What did we know when this coupon was granted?” needs Pulse ?at= (professional contract). Do not invent historical replay on the free tier.

Import the contract from https://ip99.com/openapi.json into Postman or codegen if you want typed clients. Agents can use the same lookup as MCP tool ip_risk_lookup at https://ip99.com/mcp.

What this article is not claiming

No Tor signal — do not invent one.
Risk score ≠ attacker probability.
IP99 public API evidence and ThreatHunter enterprise feeds are related products, not “the same data.”
Mask real home or mobile customer IPs in tickets and screenshots.

Paste a claim egress into ip99.com or run the free curls above. If you are shipping referral or new-user campaigns, start with evidence_state + typed signals at claim time, and keep hard IP bans rare — especially on shared residential and mobile egress.

Catch Bulk Signups Without Banning a Building: IP Risk at Registration

IP99 — Sat, 24 Oct 2026 13:11:10 +0000

Bulk registration rarely looks like a datacenter flood anymore. The signup IP often sits on ordinary broadband (usage_type: DYN), sometimes even on a cloud phone that looks like a handset. A network-type blocklist misses most of it; a hard ban on every "risky" address can take out a whole building on CGNAT. What you need at registration is a fresh, typed signal you can step up on — not a permanent label.

IP99 by ThreatHunter exposes that as a free GET /v1/ip/{ip} call: risk signals such as proxy, dialup_pool, and cloud_phone, plus evidence_state and a 0–100 score that measures freshness and strength of verifiable evidence, not "probability this person is an attacker."

What bulk signup actually buys

Fraud teams and promo farms still need three cheap inputs: phone numbers (or SMS inboxes), device surfaces, and egress IPs that rotate. The IP side has shifted off pure hosting space:

Pattern	What you tend to see	Why a DYN allowlist fails
Rotating residential / dial-up pool	`proxy` + often `dialup_pool` on residential ASN	Address is real broadband
Cloud phone farm	`cloud_phone` (and often hosting attributes)	Looks like mobile UX, not a VPS
Hijacked home exit	`hijacked_proxy`	Line owner is often a victim
Classic VPS / VPN	`proxy` / `vpn` + `usage_type: IDC`	Network-type rules catch only this row

If your registration gate only asks "is this IDC?", you are fighting last decade's inventory.

A practical registration gate (not a ban hammer)

Official triage order on IP99 is: evidence_state → score/level → which signals → (if you ever ban) share scope. On the free API you do not get Pulse share_tier; you still have usage_type and evidence_state, which is enough for a signup funnel:

evidence_state: none — no current evidence. Do not stamp the account "clean." Treat as unknown; keep normal KYC / rate limits.
stale — seen before, evidence aged out, score 0. Weak feature only; do not hard-block alone.
active + low (1–29) — log and watch; optional soft friction (email confirm, slower signup).
active + medium (30–69) — step up: captcha, device attestation, SMS or app challenge, throttle new accounts from that ASN or /24 for an hour — still prefer verify over ban.
active + high (70–100) — decide by business cost. Prefer challenge + delay over IP ban when usage_type is MOB/DYN (shared egress). If hijacked_proxy is present, do not treat the subscriber as the fraud actor; challenge the session, do not nuke the household forever.

Signals matter for the kind of step-up: cloud_phone and dialup_pool are stronger registration smells than bare hosting (network attribute — Google DNS carries hosting with score 0). crawler is benign and does not score.

Live curls (2026-10-24, no API key)

Anonymous quota is 500 lookups/day per client IP (60/min). Sign in for 5,000/day; overseas self-serve Pro is volume-only ($29 / $99) — same evidence fields. Mainland China: free + enterprise contract (no self-serve card plans on the Chinese terms page).

# Your own egress before you test signup from that network
curl https://ip99.com/v1/ip

# Public demo often used in IP99 docs (residential dial-up / proxy supply — masks in tickets)
curl https://ip99.com/v1/ip/27.22.66.200

# Datacenter control: hosting attribute, score 0
curl https://ip99.com/v1/ip/8.8.8.8

# Quota remaining (same anon bucket as lookups)
curl https://ip99.com/v1/me

Sample: residential dial-up / proxy supply (mask last octet in tickets)

Captured ~2026-10-24 13:08 UTC. Full address works in the curl above; display masks the last octet.

{
  "ip": "27.22.66.x",
  "computed_at": "2026-10-24T13:08:34Z",
  "evidence_state": "active",
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Nanzhang",
    "admin_code": "420624",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 26,
    "level": "low",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

Read left to right: still DYN home broadband; signals say dial-up pool + proxy presence, and hijacked_proxy warns the line owner may be a victim; evidence_state: active with a low score means act with friction, not a permanent ban. Scores move as evidence ages — the same IP an hour later can look different, which is intentional.

Sample: hosting control

{
  "ip": "8.8.8.8",
  "evidence_state": "none",
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

hosting alone is not a registration reject reason. Pair network type with risk signals and freshness.

Wire it into signup (minimal shape)

Pseudo-flow at POST /register after you have the client IP (trusted proxy headers only if you terminate TLS yourself):

lookup = GET https://ip99.com/v1/ip/{client_ip}
if lookup.evidence_state == "active":
  if "hijacked_proxy" in signals: challenge_session(); never permanent_ban_ip()
  elif score >= 70: challenge_or_delay(); optional short IP throttle
  elif score >= 30: captcha_or_otp(); raise_new_account_rate_limit()
  else: log_for_review()
else:
  # none / stale — unknown or expired evidence
  apply_baseline_limits_only()

CORS is open on /v1/ip, so a browser can call it, but do the gate on your server — clients lie about their IP. Import the machine-readable contract from https://ip99.com/openapi.json into Postman or your codegen if you prefer typed clients. For agents, the same lookup is also available as MCP tool ip_risk_lookup at https://ip99.com/mcp.

What this article is not promising

IP risk is not a substitute for phone / device / behavior checks; it is one cheap early signal.
Score is not attacker probability; 0 / evidence_state: none is not "safe."
Free /v1/ip answers now. Historical "what did we know at chargeback time?" needs Pulse ?at= (professional contract) — do not invent that on the free tier.
Do not advertise Tor detection; IP99's public signal set does not center on that.
Mask real residential or mobile customer IPs in tickets and blog posts (last octet is enough).

Try it

Paste a signup egress into ip99.com or hit the free curl above. If you are building registration or promo abuse controls, start with evidence_state + typed signals, and keep hard IP bans rare — especially on shared residential and mobile egress.

This Week's Proxy Exits: 11.3M New Addresses, Still Almost All Off Datacenter Space

IP99 — Fri, 23 Oct 2026 13:09:19 +0000

Datacenter blocklists are still the default proxy defence in a lot of fraud stacks. The addresses showing up in proxy supply this week mostly were not in datacenters.

Between 16–22 October 2026 (UTC), the IP99 risk feed captured 11,330,797 proxy exit addresses it had not seen in the previous 7 days (-5% vs the prior week). Source page: ip99.com/en/proxy-exits (generated 23 Oct 2026 UTC).

What those addresses sit on

Usage type	Addresses	Share
Residential broadband	8,929,906	78.8%
Mobile network	1,544,616	13.6%
Gateway / NAT egress	550,109	4.9%
Datacenter	230,551	2.0%
Education network	45,780	0.4%
Unclassified	29,835	0.3%

About 64% were rated high-risk at the moment of capture. The rest still carried a proxy-class signal at a lower risk level.

IP99 counts an address as "captured" when it enters the feed with a proxy-class signal (proxy, VPN, dial-up pool, cloud phone, or hijacked shared proxy) and was not in the live 7-day risk mirror. Addresses that go quiet and return can be counted again. The page describes what 56 upstream collection sources delivered — not the total number of proxies in the world. No address lists are published.

Why the 2% matters

If your defence is mainly an ASN or hosting blocklist, you are mostly looking at that 2.0% datacenter slice. Residential and mobile space is where home-broadband proxies and dial-up pools live. An address that keeps turning up in proxy supply is a proxy exit whatever its ISP label says.

Which networks show up most

Top ASNs in this week's capture window (by distinct address count):

ASN	Addresses	Share
AS4134	950,083	8.4%
AS4837	726,688	6.4%
AS9808	358,188	3.2%
AS36947	281,699	2.5%
AS36903	281,170	2.5%

Day-to-day shape

Captured addresses (new to the prior 7-day mirror that day), with how many were high-risk at capture:

Day (UTC)	Captured	High-risk at capture
2026-10-16	1,667,871	1,059,319
2026-10-17	1,671,080	1,036,063
2026-10-18	1,480,428	887,422
2026-10-19	1,638,525	1,098,049
2026-10-20	1,496,080	1,062,230
2026-10-21	1,679,859	1,061,464
2026-10-22	1,696,954	1,060,504

Volume eased a little week-over-week (-5%), but the mix held: residential near 79%, datacenter still about 2%. Daily capture stayed in a band roughly 1.5–1.7M addresses — no single spike day that would make a static list look "caught up."

How to use this without over-blocking

Branch on evidence, not network type. Residential is where your customers live; do not hard-block on DYN / MOB alone.
Step up, don't stop. A fresh proxy-class signal on signup, a coupon claim, or a login from a new device justifies a second factor or a delay — not an immediate ban.
Read the age. evidence_state: "stale" means the address was in supply before and is not now; treat it as a weak prior. Re-query at decision time rather than caching a verdict for days.
Keep the timestamp. Store computed_at with the decision so a disputed block can be traced back to when the observation was made.

Check one yourself

Free, no signup:

curl https://ip99.com/v1/ip/8.8.8.8

The same lookup is available to agents as an MCP tool at https://ip99.com/mcp (ip_risk_lookup). Field reference and routing notes live on the API docs.

IP99 is built by ThreatHunter. Weekly capture totals refresh daily on ip99.com/en/proxy-exits.

Dial-Up Pools Hide in Residential Space: Detect Them Without Hard-Banning Customers

IP99 — Thu, 22 Oct 2026 13:19:56 +0000

A datacenter blocklist will not catch a dial-up pool. The address is ordinary broadband: usage_type says DYN, the ASN is a consumer ISP, and geo looks like a real city. The only thing that changes is the tenant — a line that redials on demand, picks up a fresh address, and burns through hundreds of residential IPs a day before those same addresses go back to real subscribers.

That is the core idea: network type describes the pipe; dial-up pool describes how the pipe is being used right now. IP99 by ThreatHunter reports the latter as dialup_pool in risk.signals, with evidence_state and computed_at so you know whether the observation is still worth acting on.

What a dial-up pool is

A dial-up pool (Chinese ops slang: 秒拨 / miaobo, "per-second redial") is a set of ADSL or fibre lines that reconnect on demand. Each reconnect gets a new public address from the carrier — sometimes across many cities. One line can exhaust hundreds of legitimate residential addresses in a day. Later the same day, a normal household may inherit one of those addresses.

Related plumbing in the same market:

Rotating residential proxies — SDK on a phone or router; the address belongs to a real subscriber and changes hands every few minutes.
Hijacked exits — a device owned by a victim briefly sold as an exit (hijacked_proxy).
VPN / cloud phone / cloud function exits — different signals (vpn, cloud_phone, cloud_service); different disposition.

None of these need to sit in datacenter space. That is why "block IDC ASN" and "allow DYN" both fail in opposite directions.

Why usage type cannot see them

network.usage_type answers "what kind of network is this?" For dial-up pools the honest answer is residential broadband (DYN). A residential allowlist has zero precision against this product; a datacenter denylist has zero recall. The mark is not on the address — it is in observed presence in proxy supply, and that observation ages out in minutes to hours.

So you need three things together:

A signal that the address is (or was) in that supply — e.g. dialup_pool and often proxy.
How fresh that observation is — evidence_state + computed_at.
A score that compresses freshness and strength of evidence — not "probability this IP is an attacker."

Live lookups (2026-10-22)

No key. Anonymous free quota is 500/day per client IP (60/min). Signed-in free is 5,000/day; overseas self-serve Pro starts at $29/mo for volume (mainland China: free + enterprise contract only).

# Active dial-up sample (public demo IP from IP99 docs; residential samples churn)
curl https://ip99.com/v1/ip/27.22.66.200

# Homepage example that used to carry dialup_pool — today proves expiry
curl https://ip99.com/v1/ip/1.197.213.232

# Datacenter control
curl https://ip99.com/v1/ip/8.8.8.8

# Your own egress
curl https://ip99.com/v1/ip

1) Active dial-up (mask last octet in tickets)

Captured ~2026-10-22 13:15 UTC. Displayed body masks the last octet; the curl above uses the full public demo address.

{
  "ip": "27.22.66.x",
  "computed_at": "2026-10-22T13:15:10Z",
  "evidence_state": "active",
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Nanzhang",
    "admin_code": "420624",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 78,
    "level": "high",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

Read it left to right: still DYN residential space; signals say dial-up pool + proxy presence, and hijacked_proxy warns the line owner may be a victim; evidence_state: active and a mid/high score mean the evidence is fresh and strong enough to step up — not that you have proven a human attacker.

2) Same product story, opposite clock: expiry

1.197.213.232 is a public homepage sample that older docs showed around score 62 with dialup_pool + proxy. Re-fetched the same day as the active sample:

{
  "ip": "1.197.213.232",
  "computed_at": "2026-10-22T13:14:56Z",
  "evidence_state": "none",
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": { "score": 0, "level": "none" }
}

Still DYN. Score 0 with evidence_state: none means no current verifiable evidence — a blind spot, not a permanent "clean" badge. Yesterday's dial-up exit must not permanently brand tomorrow's subscriber. IP99's slogan for this: every answer is a judgement that expires, not a permanent label.

3) Datacenter control

{
  "ip": "8.8.8.8",
  "evidence_state": "none",
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

hosting (and mobile) are network attributes, not risk for scoring. Do not ban on them alone. crawler is benign and does not participate in scoring. IP99 has no Tor signal — do not invent one.

How to act on a `dialup_pool` hit

Official disposition guidance is generic, not a contract:

evidence_state first. active → the observation is current. stale → seen before, aged out to score 0; weak prior only. none → never seen here; do not treat as allowlist proof.
Step up, don't stop. Fresh proxy / dialup_pool on signup, coupon claim, or new-device login justifies CAPTCHA, second factor, delay, or rate limit — not a permanent IP or account ban on residential customers.
Read hijacked_proxy carefully. The handset or line owner is often a victim. Prefer challenge over account termination.
Store computed_at with the decision. When someone disputes a block, you need the observation time, not a naked "bad IP" tag.
Re-query at decision time. Dial-up and rotating residential evidence decays in minutes to hours. Caching a verdict across sessions recreates the false-positive gap the product is designed to close.

Score bands (same docs): 0 → do not stamp "clean"; 1–29 → log; 30–69 → verify rather than ban; 70–100 → decide by business cost, still preferring time-bounded controls on DYN.

DYN vs signals (the distinction that matters)

Field	Answers	Dial-up pool case
`network.usage_type`	Kind of network	Usually `DYN` — looks like a customer
`risk.signals`	What was observed in supply	May include `dialup_pool`, `proxy`, …
`evidence_state` + `computed_at`	Whether that observation still holds	`active` now; may be `none` hours later
`risk.score`	Freshness + strength of evidence	High when evidence is fresh; not attacker probability

If your pipeline only branches on usage_type == IDC, you will miss this class entirely. If it permanently denylists every DYN that ever scored high, you will ban the next household that inherits the address.

Try it

curl https://ip99.com/v1/ip/27.22.66.200
curl https://ip99.com/v1/ip/1.197.213.232
curl https://ip99.com/v1/ip/8.8.8.8

Start at ip99.com or the English API reference at ip99.com/api. Before the next hard ban on a "residential" IP, ask: are you blocking a pool that redials — or the subscriber who gets that address an hour later?

One Ban Is One Building: CGNAT, Shared Egress, and Ban-Scope Decisions

IP99 — Wed, 21 Oct 2026 13:19:33 +0000

Hard-banning a single public IP feels precise. On many networks it is not. Carrier-grade NAT (CGNAT), mobile egress, and enterprise gateway exits often put dozens to tens of thousands of people behind one address. When you block that address, you are not blocking "the attacker" — you are blocking everyone who happens to share the same egress today.

That is the core idea: an address is not a person. IP99 by ThreatHunter documents this as share tier on its Pulse professional API, and the same docs tell you how to approximate ban-scope decisions from free /v1/ip fields when you do not have Pulse yet.

What CGNAT and shared egress look like in practice

On a classic home broadband line, one household may share a public IP via a home router NAT. That is already multi-user, but the blast radius of a ban is usually one apartment.

CGNAT and carrier pools go further. Mobile operators (usage_type: MOB) and many enterprise / campus gateways (usage_type: GTW) put large numbers of subscribers or employees behind a small set of public addresses. One abusive session on that egress, plus a permanent IP denylist, can look like:

an entire office floor losing access after lunch,
a dorm building locked out during exam week,
or a mobile user who "keeps getting banned" every time the carrier rotates them onto a polluted pool.

The failure mode is not "your blocklist is wrong about risk." It is that the unit of enforcement (one IP) is larger than the unit of identity (one person or one device).

Share tier T0–T3 (Pulse professional context)

IP99's Pulse professional endpoint returns share_tier so you can size the blast radius before you hard-ban. From the official API docs:

Tier	Rough shared users	Typical network	Suggested handling
T0	~1–10	Dedicated / datacenter egress	Hard ban is low collateral
T1	~1–20	Home broadband NAT	Ban possible; may hit one household
T2	~50–2,000	Enterprise line, campus egress	Be careful — one ban can be a building
T3	~1,000–100,000+	Mobile cellular CGNAT	Do not hard-ban the IP; prefer challenge, rate-limit, or down-rank

Share tier also feeds scoring: the more people share an address, the harder old evidence decays, so a T3 score tends to be more conservative than a T0 score on comparable evidence.

Honest boundary: free GET /v1/ip does not return share_tier. That field is Pulse professional only (GET /pulse/v1/ip/{ip}). Do not write pipelines that expect share_tier on the anonymous free call.

What the free API does give you today

You can still make safer ban-scope decisions with free fields. No key required:

curl https://ip99.com/v1/ip/8.8.8.8
curl https://ip99.com/v1/ip

Live shapes re-fetched 2026-10-21 (Asia/Shanghai):

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-21T13:15:59Z",
  "evidence_state": "none",
  "geo": {
    "city": "Mountain View",
    "country": "US",
    "region": "California"
  },
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

{
  "ip": "140.248.50.7",
  "computed_at": "2026-10-21T13:16:00Z",
  "evidence_state": "none",
  "geo": {
    "city": "Ashburn",
    "country": "US",
    "region": "Virginia"
  },
  "network": { "asn": 54113, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

(The second call is this publisher's box egress — datacenter/IDC, so the full address is shown. Mask the last octet for residential or mobile exits in your own posts and tickets.)

Fields that matter for shared-egress triage:

network.usage_type: MOB (mobile), GTW (enterprise / gateway), DYN (residential broadband), IDC (datacenter), and others. Treat MOB / GTW as likely shared even without share_tier.
risk.signals: proxy-class hits such as proxy, vpn, dialup_pool, hijacked_proxy, plus network attributes like hosting / mobile. Do not ban on hosting or mobile alone — 8.8.8.8 carries hosting with score 0.
evidence_state: active (fresh evidence scoring), stale (seen before, aged out to 0), none (never seen — a blind spot, not "clean").
risk.score: 0–100 measuring freshness and strength of verifiable evidence, not "probability this is an attacker."

Anonymous free quota is 500 lookups/day per public IP (X-Daily-Limit / X-Daily-Remaining); signed-in free is 5,000/day. Docs: ip99.com/api.

A practical free-tier playbook

When Pulse is not available, approximate ban scope from usage type + evidence state:

Read evidence_state first. Score 0 with none means "no current evidence," not "safe to permanently allowlist." Score 0 with stale means you saw something earlier — treat it as a weak historical hint.
Classify the network. If usage_type is MOB or GTW, assume high share (T2/T3-like). Prefer CAPTCHA, step-up auth, rate limits, or feature down-rank over a permanent IP ban.
On DYN, still be careful. Home NAT is often T1-ish: a hard ban can lock out a whole household, including the victim of a hijacked_proxy (the docs note the handset owner is often a victim — do not auto-ban accounts on that signal alone).
On IDC with active proxy-class signals, hard bans are lower collateral when evidence is fresh — but still prefer time-bounded blocks. Evidence expires; permanent denylists do not.
Never treat hosting / mobile as proxy verdicts. They describe network placement, not abuse.

Official disposition guidance (generic, not a contract): scores 30–69 → verify rather than ban; 70–100 → decide by business cost and share context; on mobile CGNAT-class egress, skip the IP hard-ban entirely.

Why this matters more than another blocklist

Abuse tooling often sells "IP reputation" as a permanent label. Shared egress breaks that model twice:

Identity mismatch — one address, many people.
Time mismatch — the abusive session leaves; the address stays in your denylist for days or weeks while real users inherit it.

IP99's product stance is that every answer is a judgement that expires, not a permanent label. Free /v1/ip already exposes the fields you need to act on that idea: usage type for likely share, evidence state for trustworthiness, signals for what was observed, and a score that tracks how fresh that evidence is.

When you later need explicit share_tier T0–T3 and per-evidence freshness rows, that is what Pulse professional adds — same score, more context for ban-scope decisions.

Try it

# Any public IP
curl https://ip99.com/v1/ip/8.8.8.8

# Your own egress
curl https://ip99.com/v1/ip

# Quota / plan headers
curl -sI https://ip99.com/v1/ip/8.8.8.8 | grep -iE 'x-daily|x-plan'

Start at ip99.com or the English API reference at ip99.com/api. Before the next hard IP ban, ask one question: are you blocking a person — or a building?

From One Phish Domain to the Rest of the Cluster: Passive DNS on IP99

IP99 — Tue, 20 Oct 2026 13:14:59 +0000

Ordinary DNS answers one question: where does this name point right now? Fraud infrastructure rarely stays put. Domains rotate, IPs get swapped, registrars change. What does not change is the history of relationships that already happened.

Passive DNS (pDNS) stores those observed answers over time: which name resolved to which address, and for how long. On IP99 (by ThreatHunter) you get a free trial of that history — forward lookup, reverse lookup, and a light malware-list check — without inventing a key for the first queries.

This post walks a practical pivot: domain → historical IPs → other names on those IPs, then how to read the timestamps without fooling yourself.

Why pivoting beats a single lookup

A phishing page that was taken down yesterday still leaves footprints. The server it used three months ago often still hosts other names from the same crew. IP99's own product copy puts it bluntly: a retired phish domain's old resolver address frequently carries dozens more domains from the same operators.

That is infrastructure pivoting. Certificate Transparency (CT) can show you a lookalike was signed early. pDNS shows you where it landed and who else shared the machine. Either alone is half a picture; together they close a loop. We covered CT in an earlier post — here the focus is the DNS side.

Forward lookup: history for one name

Free trial, no key, ten queries per client IP per day (signing in does not raise this particular quota):

curl https://ip99.com/v1/domain/dns/example.com

A live call on 20 Oct 2026 (same shape as the 15 Oct check) returned corpus_last_seen: "2026-08-15", twenty-one records (A, AAAA, MX, NS, TXT), and a profile that enriched landing IPs with country, city, ASN, and ASN org. Shape (trimmed):

{
  "domain": "example.com",
  "corpus_last_seen": "2026-08-15",
  "count": 21,
  "has_more": false,
  "data": [
    {
      "rrtype": "A",
      "value": "104.20.23.154",
      "first_seen": "2026-08-15",
      "last_seen": "2026-08-15"
    }
  ],
  "profile": {
    "malware": { "listed": false, "last_listed": null, "days_listed": 0 },
    "record_types": { "A": 12, "AAAA": 2, "MX": 1, "NS": 4, "TXT": 2 }
  }
}

Six record types are covered, not only A. Mail and nameserver churn show up in the same response. Empty data: [] is a real answer (no observed rows), not an error. Bad parameters return HTTP 400 with a clear code — automate on status, not on emptiness.

Do not misread `last_seen`

This is the field people get wrong most often. IP99 imports resolution corpora in periodic batches. Seeing a last_seen a month ago usually means that snapshot's cutoff, not that the name went dark. Read last_seen against the top-level corpus_last_seen. Do not hard-code a date in your pipeline.

A separate path — newly registered domains for a calendar day — updates daily and has different time semantics. Do not apply the same interpretation to both.

Times are UTC. Aggregate by day only after you account for that.

Reverse lookup: who else shared the address

Once you have a landing IP, flip the question:

curl https://ip99.com/v1/domain/reverse/104.20.23.154

The same day's call returned 432 co-hosted names on that Cloudflare anycast address (has_more: false for that page). That volume is useful and noisy at once. Shared CDN and hosting IPs can reverse to hundreds or thousands of unrelated tenants. Treat reverse hits as candidates, then filter with CT fingerprints, malware-list days, registrar timing, or content similarity — not as automatic guilt-by-IP.

Limits to know: up to 1000 rows per response, paginate with ?offset=N and stop when has_more is false. Full-table reverse can take seconds (the service waits up to about 25s). Pass a bare address only — no :443, no /32. Private addresses are valid query values when they appear in real DNS history; they are not rejected as "invalid IP".

IP99 does not do active resolution, subdomain brute force, or one-shot bulk export of an IP's entire map through this trial surface. What you get is observed history, page by page.

Enrich the egress, not just the name

After you shortlist an IP that looks like dedicated fraud hosting (or before you block a signup from that space), check the address itself with the free no-key risk API:

curl https://ip99.com/v1/ip/8.8.8.8

Example shape from the same day:

{
  "ip": "8.8.8.8",
  "evidence_state": "none",
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] },
  "network": { "asn": 15169, "usage_type": "IDC" },
  "geo": { "country": "US", "city": "Mountain View" }
}

score is freshness and strength of verifiable risk evidence, not the probability that someone is an attacker. evidence_state: none with score 0 means no current evidence in the feed — a coverage gap, not a clean bill of health. hosting here is a network property (datacenter / CDN-class space), not a proxy verdict; do not block solely on hosting or mobile.

Anonymous quota for /v1/ip is separate from the pDNS trial (500/day per client IP; signed-in accounts get more). Same honesty rule across products: absence of a hit is not proof of safety.

A short workflow you can script

Start from a reported phish or lookalike domain.
GET /v1/domain/dns/{domain} — collect historical A/AAAA (and note NS/MX if they jumped).
For each non-CDN-looking landing IP, GET /v1/domain/reverse/{ip} — build a candidate cluster.
Cross-check interesting names with CT (/v1/domain/certs/...) when you need issuance timing.
GET /v1/ip/{ip} on egress you might gate — branch on evidence_state, then score, then signals.
Prefer step-up friction over hard bans when the address sits on shared residential or mobile space.

Optional helpers on the same free trial quota: GET /v1/domain/malware/{domain} for a millisecond list check, and GET /v1/domain/registered/{YYYY-MM-DD} for the first 1000 newly registered names that day (no pagination on that endpoint).

Coverage honesty

pDNS is observation, not authority. Sensor placement matters. Niche, brand-new, or region-local names may simply never appear. IP99 says that gap out loud: treat "we have no rows" differently from "we have rows and no malware hit." No single feed — this one included — sees the whole proxy or phishing market.

Try it

Open the interactive page at ip99.com/domain, or start with the curls above. For risk and city-level geo (China down to district) on any public IP, use ip99.com or curl https://ip99.com/v1/ip/{ip}. Docs and OpenAPI live under /api and /openapi.json if you want to generate a client instead of pasting shell.

Every answer on the risk side is a judgement that expires. On the DNS side, every row is a relationship that was observed — with a corpus clock you must read next to last_seen. Use both clocks, and you spend less time chasing ghosts.

This Week's Proxy Exits: 10.8M New Addresses, Still Almost All Off Datacenter Space

IP99 — Tue, 20 Oct 2026 00:00:38 +0000

Datacenter blocklists are still the default proxy defence in a lot of fraud stacks. The addresses showing up in proxy supply this week mostly were not in datacenters.

Between 12–18 October 2026 (UTC), the IP99 risk feed captured 10,829,683 proxy exit addresses it had not seen in the previous 7 days (-7% vs the prior week). Source page: ip99.com/en/proxy-exits (capture window still 12–18 Oct 2026 UTC as of publish).

What those addresses sit on

Usage type	Addresses	Share
Residential broadband	8,645,883	79.8%
Mobile network	1,436,705	13.3%
Gateway / NAT egress	466,938	4.3%
Datacenter	220,055	2.0%
Education network	36,064	0.3%
Unclassified	24,038	0.2%

About 63% were rated high-risk at the moment of capture. The rest still carried a proxy-class signal at a lower risk level.

IP99 counts an address as "captured" when it enters the feed with a proxy-class signal (proxy, VPN, dial-up pool, cloud phone, or hijacked shared proxy) and was not in the live 7-day risk mirror. Addresses that go quiet and return can be counted again. The page describes what 53 upstream collection sources delivered - not the total number of proxies in the world.

Why the 2% matters

Top ASNs in this week's capture window (by address count) include large access networks such as AS4134 and AS4837. That is a clue about where supply is being sold from, not a claim that every customer on those networks is a proxy.

Day-to-day shape

Captured addresses (new to the prior 7-day mirror that day), with how many were high-risk at capture:

Day (UTC)	Captured	High-risk at capture
2026-10-12	1,522,820	961,739
2026-10-13	1,501,634	953,757
2026-10-14	1,489,460	957,899
2026-10-15	1,496,390	965,299
2026-10-16	1,667,871	1,059,319
2026-10-17	1,671,080	1,036,063
2026-10-18	1,480,428	887,422

Volume cooled off after last week's spike (-7% WoW), but the mix barely moved: residential still near 80%, datacenter still about 2%.

Check one yourself

Free, no signup:

curl https://ip99.com/v1/ip/8.8.8.8

Look at evidence_state (active / stale / none), risk.score, and the proxy-class signals. A score of 0 is not "safe" - it means IP99 holds no current verifiable evidence against that address.

IP99 is built by ThreatHunter. Weekly capture totals refresh daily on ip99.com/en/proxy-exits.

DEV Community: IP99

This Week's Proxy Exits: 10.9M New Addresses, Still Almost All Off Datacenter Space

What those addresses sit on

Why the 2% matters

Which networks show up most

Day-to-day shape

How to use this without over-blocking

Check one yourself

Don't Rate-Limit Googlebot Like a Proxy Farm: Route Crawlers by IP Signal

What you are actually sorting

Triage order at the edge

Live curls (2026-10-29, no API key)

Sample A: hosting ≠ crawler ≠ proxy farm

Sample B: residential proxy churn (the scraper-shaped path)

A minimal edge hook

Context from this week's proxy exits

Try it

Cloud Phones Look Like Real Mobiles: Catch Farms at the IP Layer

What a cloud phone is (and is not)

Why device signals are not enough

Triage order (same as every other IP99 gate)

Live curls (2026-10-28, no API key)

Sample A: hosting is not cloud_phone

Sample B: residential churn ≠ handset farm

A minimal signup / claim hook

What this article is not claiming

Try it

What Did We Know at Chargeback Time? Replaying IP Risk with a Timestamp

Live gate vs chargeback clock

What to store at decision time (so replay is possible)

How to read a replay (same triage order)

Live curls (2026-10-27, no API key)

Sample A: datacenter control (score 0 is not a chargeback win)

Sample B: residential dial-up / proxy supply (mask last octet)

Minimal gate sketch (store the snapshot)

Honest limits

Try it

This Week's Proxy Exits: 11.5M New Addresses, Still Almost All Off Datacenter Space

What those addresses sit on

Why the 2% matters

Which networks show up most

Day-to-day shape

How to use this without over-blocking

Check one yourself

Stop Coupon Farms Without Banning a Building: IP Risk at Claim Time

Why claim time is a different gate than signup

A claim-time triage (step up, don’t flatten the building)

Live curls (2026-10-25, no API key)

Sample: residential dial-up / proxy supply (mask last octet)

Sample: hosting control

Wire it where the budget burns

What this article is not claiming

Catch Bulk Signups Without Banning a Building: IP Risk at Registration

What bulk signup actually buys

A practical registration gate (not a ban hammer)

Live curls (2026-10-24, no API key)

Sample: residential dial-up / proxy supply (mask last octet in tickets)

Sample: hosting control

Wire it into signup (minimal shape)

What this article is not promising

Try it

This Week's Proxy Exits: 11.3M New Addresses, Still Almost All Off Datacenter Space

What those addresses sit on

Why the 2% matters

Which networks show up most

Day-to-day shape

How to use this without over-blocking

Check one yourself

Dial-Up Pools Hide in Residential Space: Detect Them Without Hard-Banning Customers

What a dial-up pool is

Why usage type cannot see them

Live lookups (2026-10-22)

1) Active dial-up (mask last octet in tickets)

2) Same product story, opposite clock: expiry

3) Datacenter control

How to act on a dialup_pool hit

DYN vs signals (the distinction that matters)

Try it

One Ban Is One Building: CGNAT, Shared Egress, and Ban-Scope Decisions

What CGNAT and shared egress look like in practice

How to act on a `dialup_pool` hit

Do not misread `last_seen`