DEV Community: IP99

Don't Ban on a Public List Alone: Reading osint on IP99

IP99 — Sun, 08 Nov 2026 13:13:45 +0000

Public IP blocklists feel definitive: if an address showed up in open-source intelligence, refuse it. That treats a listing as a permanent identity. Addresses change hands; community lists refresh on a slower clock. On IP99 by ThreatHunter, osint names something narrower: the address was listed by a public intelligence source. It is a risk tag, not a probability that the person behind the IP is an attacker, and not a reason to skip the rest of the triage.

This walkthrough stays on free, no-key GET /v1/ip/{ip}. JSON samples below are documented product shapes from IP99 docs and prior verified captures — run the curls yourself for a live snapshot. We use a documented capture that already carries osint alongside other slugs; we do not invent a sample IP that carries osint alone. Notes: IP99, API, detect proxy / VPN, IP risk score.

What `osint` is (and what it is not)

IP99's free lookup returns a 0–100 risk.score for freshness and strength of verifiable risk evidence, not attacker probability. risk.level follows the score (0 → none, 1–29 → low, 30–69 → medium, 70–100 → high). Signals appear only when they hit. Always branch on evidence_state (active / stale / none) before the score: score 0 + none is a coverage gap, not a clean bill of health.

Tags that matter here:

slug	Meaning	Typical disposition
`osint`	Listed by a public intelligence source (risk tag)	Step-up; do not hard-ban on a listing alone
`proxy`	Address currently used as a proxy exit	Step-up or block by business cost
`vpn`	Static commercial VPN exit	Product decision; often step-up, not refuse
`dialup_pool`	Dial-up / redial rotation pool	Supply-side rotation (often DYN/MOB)
`hijacked_proxy`	Malware-hijacked egress; owner is the victim	Challenge, do not ban the account
`hosting` / `mobile`	Network attributes	Not risk verdicts alone
`crawler`	Search crawler egress	Benign; does not score

Official API wording: osint = listed by a public intelligence source (open-source intelligence). It can appear in risk.signals and, on Pulse, as an evidence[].risk_type row. The docs do not name upstream list vendors, and this article does not invent them.

False equivalents:

osint ≠ "this user is an attacker." The score measures evidence freshness and strength. A listing is an observation about an address, not attribution of a person. Shared exits put many unrelated users behind one IP.
osint ≠ proxy / vpn / dialup_pool. Those tags come from observed proxy-class use or commercial VPN infrastructure. osint means a public source listed the address. They can appear together; they are not synonyms.
hosting on IDC ≠ osint. Public DNS and ordinary cloud servers sit in hosting space every day with score 0 and no public-intel hit.
crawler is benign and does not score — do not fold a search crawler into an OSINT block.

Free /v1/ip does not return share_tier (Pulse only). On free tier, lean on evidence_state, score/level, signal type, usage_type, plus your own velocity / device checks.

Why public listings go stale

IP99's detect-proxy/VPN guide puts it plainly: two clocks run at different speeds. The address changes hands in minutes; the list that describes it is refreshed in days. The gap is where false positives live — a real customer gets the address a list still describes as yesterday's exit.

That is why IP99 treats every answer as a judgement that expires, not a permanent label. When osint is present, read evidence_state and computed_at with it. active means fresh scoring evidence; stale means it was seen but has aged out (score 0, weak feature only); none means never seen — unknown, not safe.

Official corollary from the same page: no source is complete. Proxy supply is a market; every vendor sees a slice of it. Treat any single feed, IP99 included, as one input among several. A public listing is useful context, not a substitute for first-party proxy / dialup_pool evidence.

Documented contrast: hosting without a listing vs listing plus proxy vs proxy without osint

curl https://ip99.com/v1/ip/8.8.8.8?utm_source=devto&utm_medium=article&utm_campaign=ip99

Documented product sample (IP99 docs / prior verified capture):

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-09T10:22:26Z",
  "evidence_state": "none",
  "geo": {
    "continent": "NA",
    "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 a network attribute on public DNS. evidence_state: none with score 0 means no verifiable proxy-class or public-intel evidence on file — not "safe," and not osint. Blocking every address that "looks listed" or "looks like a datacenter" would refuse this one for the wrong reason.

Now a Paris datacenter address whose documented capture included osint together with proxy and hosting:

curl https://ip99.com/v1/ip/178.20.30.146?utm_source=devto&utm_medium=article&utm_campaign=ip99

Documented product sample (IP99 docs / prior verified capture):

{
  "ip": "178.20.30.146",
  "computed_at": "2026-10-09T10:23:02Z",
  "evidence_state": "active",
  "geo": {
    "continent": "EU",
    "country": "FR",
    "region": "Île-de-France",
    "city": "Paris",
    "tz": "Europe/Paris"
  },
  "network": { "asn": 46475, "usage_type": "IDC" },
  "risk": {
    "score": 99,
    "level": "high",
    "signals": ["hosting", "osint", "proxy"]
  }
}

This is the documented shape we can show: osint matched, and so did proxy. Branch on each matched slug. proxy means observed proxy egress; osint means a public intelligence source listed it; hosting is only the network attribute. Do not collapse the three into "bad IP, ban." We are not inventing a solo-osint address — if a live lookup later drops a slug, that is expected, because scores decay.

Most new proxy supply is not in that IDC slice. API docs demo for a residential proxy egress without osint:

curl https://ip99.com/v1/ip/86.111.136.23?utm_source=devto&utm_medium=article&utm_campaign=ip99

Documented product sample (API docs demo): score 86, level high, signals ["proxy"], usage_type DYN, ASN 15547, geo CH / Valais / Sitten. Re-curl for a live snapshot — scores decay with evidence age. First-party proxy observation can exist without a public listing, just as a listing can linger after the address changed hands.

What the weekly capture mix says

Between 1–7 November 2026 (UTC), IP99 captured 10,728,498 new proxy-class exit addresses (+3% WoW). By usage type: 79.2% residential (8,498,288), 12.3% mobile (1,316,500), 4.0% gateway/NAT (425,657), 3.7% datacenter (391,719). 58 upstream sources. Figures generated 8 November 2026 UTC. Source: proxy-exits. Aggregates only; no address lists.

That weekly count is first-party proxy-class observation (proxy, VPN, dial-up pool, cloud phone, or hijacked shared proxy) — not a count of osint listings. The mix still matters: most new exits sit in residential space. Trusting only public lists, or only blocking IDC, under-covers that majority and over-punishes leftover listings after an address changed hands.

A practical branch (evidence_state first)

Official triage order: evidence_state → score/level → signal type → usage_type. Generic guidance (not a contract): score 0 → do not stamp "clean"; 1–29 → observe; 30–69 → captcha / throttle / second factor; 70–100 → block only when business cost allows. Score meaning: IP risk score.

1. Read evidence_state (active / stale / none).
2. Read risk.signals and network.usage_type.
3. If osint is present and evidence_state is active:
     - Treat as "listed by a public intelligence source."
     - Do NOT treat the listing as attacker probability or as a person-level verdict.
     - Prefer step-up + velocity / device / session checks over a hard ban on the listing alone.
     - If proxy / vpn / dialup_pool are also present, branch on those slugs too — they are different observations.
4. If osint is present and evidence_state is stale:
     - Weak, expired feature only (score 0). Do not apply an old list hit as a fresh ban.
5. Else if hosting on IDC WITHOUT osint / proxy / vpn:
     - Network attribute only — do not invent a public-intel verdict.
6. Else if proxy on DYN or MOB without osint:
     - First-party proxy supply, not a public listing — different from osint-only reasoning.
7. If hijacked_proxy is also present: challenge; do not ban the account (owner is the victim).
8. Never mark score 0 + evidence_state none as "trusted clean."
9. Re-query at decision time; do not cache an osint verdict for days.

Anonymous quota is 500 lookups/day per client IP (60/min); a free logged-in key raises the daily cap to 5,000/day. Check remaining with GET https://ip99.com/v1/me?utm_source=devto&utm_medium=article&utm_campaign=ip99 or the X-Daily-* headers. OpenAPI: https://ip99.com/openapi.json?utm_source=devto&utm_medium=article&utm_campaign=ip99. Pricing: https://ip99.com/en/pricing?utm_source=devto&utm_medium=article&utm_campaign=ip99.

Do not treat IP99 scores as identical to other ThreatHunter datasets — this article only claims what free /v1/ip and the cited English product pages / OpenAPI document.

Try it

curl https://ip99.com/v1/ip?utm_source=devto&utm_medium=article&utm_campaign=ip99
curl https://ip99.com/v1/ip/8.8.8.8?utm_source=devto&utm_medium=article&utm_campaign=ip99
curl https://ip99.com/v1/ip/178.20.30.146?utm_source=devto&utm_medium=article&utm_campaign=ip99
curl https://ip99.com/v1/ip/86.111.136.23?utm_source=devto&utm_medium=article&utm_campaign=ip99
curl https://ip99.com/v1/me?utm_source=devto&utm_medium=article&utm_campaign=ip99

IP99 is a ThreatHunter product. Use the free lookup to separate a public intelligence listing (osint) from first-party proxy observation, commercial VPN exits, ordinary hosting, and leftover labels after an address changed hands — before a stale list hit bans a customer who just received the IP. Start at https://ip99.com?utm_source=devto&utm_medium=article&utm_campaign=ip99; read detect proxy / VPN, proxy-exits, and https://ip99.com/api?utm_source=devto&utm_medium=article&utm_campaign=ip99.

Serverless Exits Still Leave Fingerprints: Reading cloud_service on IP99

IP99 — Sat, 07 Nov 2026 13:16:12 +0000

Serverless and cloud-function platforms share egress. Your webhook, cron, or Lambda-style worker can look identical on the wire to someone else's — same ASN, same hosting NAT. Blanket-blocking every IDC address hits honest automation and still misses most proxy supply. On IP99 by ThreatHunter, cloud_service names something narrower: a cloud function / serverless egress observed as a risk tag — not "any hosting IP," not a commercial VPN static exit, and not a cloud-phone farm.

This walkthrough stays on free, no-key GET /v1/ip/{ip}. JSON samples below are documented product shapes from IP99 docs and prior verified captures — run the curls yourself for a live snapshot. We do not invent a sample IP that carries cloud_service; the official slug meaning and triage order are enough. Notes: IP99, API, detect proxy / VPN, proxy exits.

What `cloud_service` is (and what it is not)

Tags that matter here:

slug	Meaning	Typical disposition
`cloud_service`	Cloud function / serverless egress (risk tag)	Shared egress — step-up / velocity; do not assume one human
`cloud_phone`	Cloud phone (handset / farm device in a datacenter)	Different pattern; do not conflate with serverless
`proxy`	Address currently used as a proxy exit	Step-up or block by business cost
`vpn`	Static commercial VPN exit	Product decision; often step-up, not refuse
`dialup_pool`	Dial-up / redial rotation pool	Supply-side rotation (often DYN/MOB)
`hosting` / `mobile`	Network attributes	Not risk verdicts alone
`crawler`	Search crawler egress	Benign; does not score

Official API / OpenAPI wording: cloud_service = a cloud function / serverless egress. It is a risk signal from observed evidence, not from "looks like AWS." Hosting alone never puts cloud_service in risk.signals.

Brief contrast with cloud_phone (earlier article): a cloud phone is a handset / farm device remoted for bulk signup; serverless egress is function/worker infrastructure sharing a cloud NAT. Same IDC neighborhood sometimes — different signal, different response. Do not reuse a cloud-phone ban for every Lambda customer.

False equivalents:

hosting on IDC ≠ cloud_service. Public DNS and ordinary VMs sit in hosting space every day with score 0.
proxy / vpn / dialup_pool ≠ serverless. Residential rotation, commercial VPN static exits, and dial-up pools are different supply classes.
crawler is benign and does not score — do not fold it into a serverless block.

Free /v1/ip does not return share_tier (Pulse only). On free tier, lean on evidence_state, score/level, signal type, usage_type, plus your own velocity / device checks.

Documented contrast: hosting attribute vs IDC proxy vs residential supply

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

Documented product sample (IP99 docs / prior verified capture):

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-09T10:22:26Z",
  "evidence_state": "none",
  "geo": {
    "continent": "NA",
    "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 a network attribute on public DNS. evidence_state: none with score 0 means no verifiable proxy-class evidence on file — not "safe," and not cloud_service. "Block all IDC" would refuse this address for the wrong reason.

Now a Paris datacenter address with proxy evidence (contrast: proxy on IDC, not cloud_service):

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

Documented product sample (IP99 docs / prior verified capture):

{
  "ip": "178.20.30.146",
  "computed_at": "2026-10-09T10:23:02Z",
  "evidence_state": "active",
  "geo": {
    "continent": "EU",
    "country": "FR",
    "region": "Île-de-France",
    "city": "Paris",
    "tz": "Europe/Paris"
  },
  "network": { "asn": 46475, "usage_type": "IDC" },
  "risk": {
    "score": 99,
    "level": "high",
    "signals": ["hosting", "osint", "proxy"]
  }
}

Same IDC + hosting neighborhood many serverless exits share, but the matched slug here is proxy (plus osint), not cloud_service. Branch on the matched signal, not on "looks like a datacenter."

Most new proxy supply is not in that IDC slice. API docs demo for a residential proxy egress:

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

What the weekly capture mix says

Between 31 October – 6 November 2026 (UTC), IP99 captured 10,653,453 new proxy-class exit addresses (±0% WoW). By usage type: ~79% residential (8,410,793 / 78.9%), 12.4% mobile, 4.1% gateway/NAT, 3.7% datacenter (391,549). 58 upstream sources. Source: proxy-exits. Aggregates only; no address lists.

Most new proxy supply is not datacenter/serverless space. Blocking only IDC under-covers residential exits that dominate the feed, while over-punishing legitimate cloud workers that share those ranges without a cloud_service (or other risk) hit.

A practical branch (evidence_state first)

1. Read evidence_state (active / stale / none).
2. Read risk.signals and network.usage_type.
3. If cloud_service is present and evidence_state is active:
     - Treat as shared cloud-function / serverless egress.
     - Do NOT assume a single human behind the IP.
     - Prefer step-up + velocity / device / session binding over refuse.
     - Do NOT hard-ban every customer whose traffic happens to leave via a public cloud NAT.
4. Else if hosting on IDC WITHOUT cloud_service / proxy / vpn / dialup_pool:
     - Network attribute only — do not invent a serverless verdict.
5. Else if cloud_phone (active):
     - Different playbook (device-farm pattern) — do not reuse as "Lambda ban."
6. Else if proxy / dialup_pool on DYN or MOB:
     - Residential / mobile proxy supply — different from serverless.
7. Never mark score 0 + evidence_state none as "trusted clean."
8. Re-query at decision time; do not cache a cloud_service verdict for days.

Anonymous quota is 500 lookups/day per client IP (60/min); a free logged-in key raises the daily cap to 5,000/day. Check remaining with GET https://ip99.com/v1/me or the X-Daily-* headers. OpenAPI: https://ip99.com/openapi.json. Pricing: https://ip99.com/en/pricing.

Do not treat IP99 scores as identical to other ThreatHunter datasets — this article only claims what free /v1/ip and the cited English product pages / OpenAPI document.

Try it

curl https://ip99.com/v1/ip
curl https://ip99.com/v1/ip/8.8.8.8
curl https://ip99.com/v1/ip/178.20.30.146
curl https://ip99.com/v1/ip/86.111.136.23
curl https://ip99.com/v1/me

IP99 is a ThreatHunter product. Use the free lookup to separate serverless / cloud-function egress (cloud_service) from ordinary hosting, commercial VPN exits, residential proxy supply, and cloud-phone farms — before a blanket IDC ban hits legitimate automation. Start at https://ip99.com; read detect proxy / VPN, proxy exits, and https://ip99.com/api.

Is This IP a VPN? Reading the vpn Signal Without Blanket Blocks

IP99 — Fri, 06 Nov 2026 14:17:18 +0000

Blanket-blocking every address that looks like a VPN is a product decision dressed up as security. On IP99 by ThreatHunter, the vpn signal means something narrower: a static commercial VPN exit on infrastructure the provider controls — usually a fixed hosting/dedicated address, shared by many users and stable for weeks. That is the opposite of a rotating residential proxy. Treating hosting alone, or every IDC address, as "VPN → refuse" over-blocks privacy users and travellers while still missing proxy supply that wants to look like a customer.

What `vpn` is (and what it is not)

Tags that matter here:

slug	Meaning	Typical disposition
`vpn`	Static commercial VPN exit (observed infrastructure)	Product decision; often step-up, not refuse
`proxy`	Address currently used as a proxy exit	Step-up or block by business cost
`dialup_pool`	Dial-up / redial rotation pool	Treat as supply-side rotation (often DYN/MOB)
`hosting` / `mobile`	Network attributes	Not risk verdicts alone
`crawler`	Search crawler egress	Benign; does not score

Official page shape for a commercial VPN exit (is-this-ip-a-vpn):

Hosting or dedicated ranges — providers rent datacenter servers, so network.usage_type is usually IDC and risk.signals often also lists hosting.
Static — the same address serves the same provider for weeks or months; evidence ages slowly compared with rotating exits.
Shared — many users sit behind one exit at once; the address's history must not attach to the next person behind it.
Observed, not inferred — vpn comes from observed VPN infrastructure, not from network type. Hosting alone never puts vpn there.

Two common mistakes:

IDC + hosting ≠ VPN. A datacenter address without vpn evidence is hosting, not a VPN. Public DNS and ordinary cloud servers look like that every day.
"VPN" apps on consumer devices ≠ commercial VPN exits. Apps that route through phones or home routers are residential proxy supply. IP99 reports those as proxy / dialup_pool on DYN or MOB space — detected by presence in proxy supply, not by calling them VPN.

Tor is not a VPN: Tor uses volunteer relays; a VPN is a commercial service with fixed provider-controlled exits. This article covers VPN/proxy infrastructure only — do not invent a Tor tag, and do not claim IP99 detects Tor.

Free /v1/ip does not return share_tier (Pulse only). On free tier, lean on evidence_state, score/level, signal type, plus your own velocity / device checks.

Documented contrast: hosting attribute vs datacenter proxy

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

Documented product sample (IP99 docs / prior verified capture):

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-09T10:22:26Z",
  "evidence_state": "none",
  "geo": {
    "continent": "NA",
    "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 a network attribute on public DNS. evidence_state: none with score 0 means no verifiable proxy-class evidence on file — not a clean bill of health, and not a VPN. "Block all IDC" would refuse this address for the wrong reason.

Now a Paris datacenter address with proxy evidence (contrast: proxy on IDC, not vpn):

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

Documented product sample (IP99 docs / prior verified capture):

{
  "ip": "178.20.30.146",
  "computed_at": "2026-10-09T10:23:02Z",
  "evidence_state": "active",
  "geo": {
    "continent": "EU",
    "country": "FR",
    "region": "Île-de-France",
    "city": "Paris",
    "tz": "Europe/Paris"
  },
  "network": { "asn": 46475, "usage_type": "IDC" },
  "risk": {
    "score": 99,
    "level": "high",
    "signals": ["hosting", "osint", "proxy"]
  }
}

Same IDC + hosting space as many VPN exits, but the slug here is proxy (plus osint), not vpn. Branch on the matched signal, not on "looks like a datacenter." When vpn appears on a fresh active response, treat the egress as a shared commercial exit: challenge where product rules require it, but do not attach prior account history to the next user behind that IP.

What the weekly capture mix says

VPN-style infrastructure and rotating proxy supply live in different places. Of the 10,638,587 new proxy exit addresses captured in the 7 days to 5 November 2026, only 4% sat in datacenter space; 79% were residential broadband. Source: proxy-exits (also cited on is-this-ip-a-vpn; page data risk:20261106211046 geo:20261106). Someone who wants to look like a customer does not buy a static commercial VPN. A hosting-only blocklist over-punishes legitimate VPN users and under-covers residential exits that dominate new supply.

A practical branch (evidence_state first)

Official triage order: evidence_state → score/level → signal type. Generic guidance (not a contract): score 0 → do not stamp the IP "clean"; 1–29 → observe; 30–69 → captcha / throttle / second factor rather than a hard ban; 70–100 → block only when business cost allows. Score meaning and freshness notes: IP risk score.

1. Read evidence_state (active / stale / none).
2. Read risk.signals and network.usage_type.
3. If vpn is present and evidence_state is active:
     - Decide what VPN means for YOUR product (privacy vs licensing / geo / promo rules).
     - Treat the exit as shared — never attach prior account history to the next user.
     - Read geo.country as the EXIT country, not the user's home country.
     - Prefer step-up + velocity/device over refuse for most consumer flows.
4. Else if hosting on IDC WITHOUT vpn / proxy / dialup_pool:
     - Network attribute only — do not invent a VPN verdict.
5. Else if proxy / dialup_pool on DYN or MOB:
     - Residential / mobile proxy supply — different playbook than commercial VPN.
6. Never mark score 0 + evidence_state none as "trusted clean."
7. Re-query at decision time; do not cache a VPN verdict for days.

Anonymous quota is 500 lookups/day per client IP (60/min); a free logged-in key raises the daily cap to 5,000/day. Check remaining with GET https://ip99.com/v1/me or the X-Daily-* response headers. OpenAPI: https://ip99.com/openapi.json.

Do not treat IP99 scores as identical to other ThreatHunter datasets elsewhere — this article only claims what free /v1/ip and the cited English product pages document.

Try it

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

IP99 is a ThreatHunter product. Use the free lookup to separate commercial VPN static exits from residential proxy supply and ordinary hosting before a blanket ban hits a legitimate privacy user. Start at https://ip99.com; read Is this IP a VPN?, detect proxy / VPN, and https://ip99.com/api.

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

IP99 — Thu, 05 Nov 2026 13:12:37 +0000

Datacenter blocklists still look like the default proxy defence in a lot of fraud stacks. The addresses showing up in proxy supply this week mostly were not in datacenters — though the datacenter slice did tick up from the flat ~2% band of recent weeks.

Between 29 October – 4 November 2026 (UTC), the IP99 risk feed captured 10,576,402 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 5 November 2026 UTC).

What those addresses sit on

Usage type	Addresses	Share
Residential broadband	8,308,606	78.6%
Mobile network	1,355,233	12.8%
Gateway / NAT egress	441,993	4.2%
Datacenter	376,455	3.6%
Education network	55,304	0.5%
Unclassified	38,811	0.4%

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 57 upstream collection sources delivered — not the total number of proxies in the world. No address lists are published.

Why 3.6% still is not "mostly datacenter"

If your defence is mainly an ASN or hosting blocklist, you are still mostly looking past the problem. Residential broadband alone is 78.6% of this week's capture window. Mobile adds another 12.8%. Together that is over 90% of newly seen proxy exits sitting in access networks where real customers also live.

The datacenter row moved from about 2.0% in the prior complete week (26 Oct – 1 Nov) to 3.6% here. That is a real mix shift in what the collectors delivered into the mirror — worth watching — but it does not flip the headline. A hosting-only blocklist still misses the majority of the supply-side traffic that shows up as residential or mobile exits.

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. Product notes: rotating residential proxies, detect proxy / VPN.

Which networks show up most

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

ASN	Addresses	Share
AS4134	959,474	9.1%
AS4837	720,839	6.8%
AS9808	347,983	3.3%
AS6057	251,108	2.4%
AS55836	231,901	2.2%

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. ASN pages for deeper network mix: ip99.com/en/asn/.

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-29	1,430,961	917,972
2026-10-30	1,529,687	940,305
2026-10-31	1,442,095	886,256
2026-11-01	1,367,730	828,494
2026-11-02	1,410,781	835,680
2026-11-03	1,642,470	1,080,877
2026-11-04	1,752,678	1,169,732

Volume eased week-over-week (−6% after the prior ~10.3M window), while upstream sources sat at 57. The softer headline is about what those collectors delivered into the 7-day mirror, not a claim that proxy supply worldwide shrank. Daily capture stayed in a band roughly 1.37–1.75M addresses, with 3–4 Nov the heavier days inside this window — still not a shape that makes 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. Score 0 with evidence_state: "none" is not a clean bill of health either — it means no current verifiable evidence is on file.
Keep the timestamp. Store computed_at with the decision so a disputed block can be traced back to when the observation was made.

IP99 by ThreatHunter publishes the free weekly aggregate so you can see the mix without buying a feed. The score on a single lookup is the freshness and strength of verifiable risk evidence — not a probability that the address "is an attacker." Do not treat IP99 scores as identical to every other ThreatHunter dataset you may have seen elsewhere; this article only claims what the public proxy-exits page and free /v1/ip document.

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. Public DNS infrastructure often shows a hosting network attribute with score 0 and evidence_state: "none" — that is a network fact, not a proxy verdict. 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.

Try it on ip99.com, keep an eye on this week's proxy exits, and wire the free OpenAPI at ip99.com/openapi.json if you want the same fields in Postman or codegen.

Don't Ban the Hijacked Exit: Reading hijacked_proxy Without Punishing Victims

IP99 — Wed, 04 Nov 2026 13:12:45 +0000

Most antifraud stacks treat every proxy-class signal as "hostile egress — ban the account." That is the wrong move for one of the ten signals on IP99 by ThreatHunter: hijacked_proxy. The documented meaning is an address that has been pressed into proxy service after compromise — often malware on a real household or SMB machine. The person whose account just hit your login or checkout may be the victim, not the pool operator. Hard-banning them for the IP alone turns a supply-side signal into collateral damage.

This walkthrough stays on the free, no-key GET /v1/ip/{ip} endpoint. Live samples were captured on 2026-11-04 (~13:10 UTC). Product docs and the English API guide: IP99, API, detect proxy / VPN.

What `hijacked_proxy` is (and is not)

IP99's free lookup returns a 0–100 risk.score that measures freshness and strength of verifiable risk evidence, not "probability this user is an attacker." risk.level is derived from the score (0 → none, 1–29 → low, 30–69 → medium, 70–100 → high). Signals appear only when they hit; missing keys mean unknown, not zero.

Among the risk tags:

slug	Meaning	Typical disposition
`proxy`	Address currently used as a proxy exit	Step-up or block by business cost
`vpn`	Static commercial VPN exit	Often step-up; rarely "customer is malware"
`dialup_pool`	Dial-up / redial rotation pool	Treat as supply-side rotation
`hijacked_proxy`	Address hijacked into shared proxy capacity	Do not auto-ban the account holder
`cloud_phone` / `cloud_service`	Datacenter handset / serverless egress	Farm / automation shapes
`crawler`	Search crawler egress	Benign; does not score
`hosting` / `mobile`	Network attributes	Not risk verdicts

Official generic guidance (not a contract): score 0 → do not stamp the IP "clean"; 1–29 → observe; 30–69 → captcha / throttle / second factor rather than a hard ban; 70–100 → block only when cost allows. The docs call out hijacked_proxy specifically: that address should not be banned outright. Before any IP ban, Pulse customers also check share_tier (T0–T3) for blast radius — free /v1/ip does not return share_tier, so on the free tier lean harder on step-up and signal type.

Do not invent Tor or other tags that are not in the JSON. Do not treat IP99 scores as identical to every other ThreatHunter dataset you may have seen elsewhere — this article only claims what /v1/ip returns.

Live contrast: clean hosting attribute vs leftover hijack tags

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

Captured 2026-11-04T13:09:55Z:

{
  "ip": "8.8.8.8",
  "computed_at": "2026-11-04T13:09:55Z",
  "evidence_state": "none",
  "geo": {
    "continent": "NA",
    "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 a network attribute on public DNS infrastructure. evidence_state: none with score 0 means no verifiable proxy-class evidence on file — not a clean bill of health, and not a hijack.

Now a residential demo address that has historically shown proxy-supply tags. Full address works in curl; tickets and screenshots should mask the last octet.

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

Captured 2026-11-04T13:10:00Z (last octet masked in the body):

{
  "ip": "27.22.66.x",
  "computed_at": "2026-11-04T13:10:00Z",
  "evidence_state": "stale",
  "geo": {
    "continent": "AS",
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Yicheng",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

evidence_state: stale forces the score to 0, but leftover signal slugs remain as a weak feature. Seeing hijacked_proxy beside proxy and dialup_pool on DYN (residential broadband) space is exactly the shape where "ban the IP → ban the household" is the wrong first move. Prefer step-up auth, device binding, or a temporary hold while you check whether the account looks like a farm.

When evidence_state is active and score is mid/high with hijacked_proxy, the same rule holds: treat the egress as contaminated, not the human as proven fraud. Combine with non-IP signals (device, payment, velocity). If you only have free /v1/ip, you lack share_tier — so default to verification over permanent IP bans on residential / mobile usage types.

A practical branch for login and support

1. Read evidence_state (active / stale / none).
2. Read risk.signals.
3. If hijacked_proxy is present:
     - Do NOT auto-ban the account for IP alone.
     - Prefer MFA / captcha / cool-down.
     - For support tickets: offer "your network may be infected or shared" language, not "you are a proxy reseller."
4. Else if proxy / vpn / dialup_pool / cloud_phone without hijacked_proxy:
     - Apply your normal supply-side policy (step-up vs block by score + product cost).
5. Never mark score 0 + evidence_state none as "trusted clean."

Anonymous quota is 500 lookups/day per public IP (60/min); a free logged-in key raises the daily cap. Check remaining with GET https://ip99.com/v1/me or the X-Daily-* response headers. OpenAPI: https://ip99.com/openapi.json. Weekly aggregates of newly captured proxy-class exits (no address lists): https://ip99.com/en/proxy-exits.

Try it

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

IP99 is a ThreatHunter product. Use the free lookup to separate hijacked residential exits from intentional VPN/proxy supply before your ban hammer hits the wrong person. Start at https://ip99.com and the English API notes at https://ip99.com/api.

Score Zero Has Two Meanings: Branch on evidence_state First

IP99 — Tue, 03 Nov 2026 13:15:34 +0000

If your antifraud rule treats every risk.score == 0 as "clean," you will misread two very different situations the same way. On IP99 by ThreatHunter, score zero can mean never seen (evidence_state: none) or seen before, evidence window expired (evidence_state: stale). Both print 0. Only one of them is a coverage gap; the other is a fading memory with leftover signal slugs. The documented read order starts with evidence_state for that reason.

This walkthrough stays on the free, no-key GET /v1/ip/{ip} endpoint. Live samples were captured on 2026-11-03 (~13:11 UTC).

What `evidence_state` actually means

IP99's risk score is freshness and strength of verifiable risk evidence, on a 0–100 scale that decays as evidence ages. It is not the probability that an address is an attacker. risk.level is derived from the score: 0 → none, 1–29 → low, 30–69 → medium, 70–100 → high.

evidence_state tells you whether that score is even in play:

`evidence_state`	Meaning	Score behavior
`active`	Fresh enough evidence to participate in scoring	Score can be 1–100
`stale`	Address was seen before; evidence window expired	Forced to 0; leftover signals are a weak feature
`none`	Never seen in the risk evidence set	Also 0; coverage gap — not "safe"

Official disposition guidance (generic advice, not a contract): score 0 → do not mark the IP clean; 1–29 → observe; 30–69 → step-up (captcha, throttle, second factor) rather than a hard ban; 70–100 → block only when business cost allows. hijacked_proxy should not automatically ban the account holder — that address is often a victim of malware-turned-exit capacity.

Example A: score 0 + `none` (never seen as risk evidence)

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

Captured 2026-11-03T13:11:32Z:

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

usage_type: IDC and signals: ["hosting"] are network attributes, not a proxy verdict — Google Public DNS lives in hosting space. evidence_state: none with score 0 means IP99 holds no current verifiable risk evidence for this address. That is not a clean bill of health; it is "we have nothing risk-shaped on file." Do not invent Tor or other signals that are not in the response.

Example B: score 0 + `stale` (same demo IP, different day)

Public docs often demonstrate with a residential dial-up / proxy-supply address. Full address works in curl; prose and tickets should mask the last octet.

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

Captured 2026-11-03T13:11:48Z (last octet masked in the body):

{
  "ip": "27.22.66.x",
  "computed_at": "2026-11-03T13:11:48Z",
  "evidence_state": "stale",
  "geo": {
    "continent": "AS",
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Yicheng",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

Same score shape as Example A — 0 / none — but a different story. usage_type: DYN is residential broadband. The signal list still carries proxy, dialup_pool, and hijacked_proxy. On 2026-11-01, this same demo address returned evidence_state: active with a low non-zero score. Today the window has expired: score is forced to 0, state is stale, and those slugs survive as a weak feature — useful for logging and soft routing, not as a fresh "ban now" trigger.

If your code only checks score == 0, Examples A and B collapse into one bucket. Branch on evidence_state first and they stay distinct: A is a gap; B is expired evidence that still names the historical observation types.

The decision order (free `/v1/ip`)

IP99's documented order is intentionally boring:

evidence_state — is the conclusion even scorable right now?
risk.score / risk.level — how strong/fresh is the evidence when active?
risk.signals — branch by type (proxy / vpn / dialup_pool / cloud_phone vs crawler vs network attributes hosting / mobile).
Ban scope — on Pulse, share_tier (T0–T3) decides whether an IP ban hits one tenant or a whole CGNAT building. The free /v1/ip response does not include share_tier; keep that in mind before hard-blocking.
degraded — if present, some upstreams were unavailable; discount the answer.

A small branch that matches the schema:

if evidence_state == "none" and score == 0:
    do_not_mark_clean()          # coverage gap
elif evidence_state == "stale" and score == 0:
    log_weak_feature(signals)    # expired memory; soft weight only
elif evidence_state == "active":
    if score >= 70:
        block_if_business_allows()
    elif score >= 30:
        step_up()                # captcha / throttle / review
    else:
        observe()
# hosting / mobile in signals → network context only; never sole ban reason
# hijacked_proxy → step-up, not automatic account ban

Anti-patterns this avoids: treating every zero as trusted; caching yesterday's label without storing computed_at + evidence_state; equating hosting with fraud; hard-banning on hijacked_proxy alone.

Try it without a key

curl https://ip99.com/v1/ip/8.8.8.8
curl https://ip99.com/v1/ip/27.22.66.200
curl https://ip99.com/v1/ip          # caller's own egress
curl https://ip99.com/v1/me          # quota / plan headers context

Anonymous quota is 500 lookups/day per client IP and 60/min, resetting at midnight Asia/Shanghai. CORS is open (Access-Control-Allow-Origin: *). Machine-readable contract: OpenAPI. Field deep-dives: evidence freshness, risk score, detect proxy/VPN, and the English API reference.

Paid volume plans change quotas, not the free answer shape. Per-evidence rows, share_tier, and ?at= history sit on Pulse (professional).

Takeaway

Score zero is ambiguous until you read evidence_state. none means no risk evidence on file. stale means evidence existed, the scoring window expired, and leftover signal slugs are weak features — not a fresh verdict. Branch on state first, then score, then signal type. For the free lookup and field definitions, start at ip99.com.

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

IP99 — Mon, 02 Nov 2026 13:10:58 +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 26 October – 1 November 2026 (UTC), the IP99 risk feed captured 10,256,050 proxy exit addresses it had not seen in the previous 7 days (−11% vs the prior week). Source page: ip99.com/en/proxy-exits (generated 2 Nov 2026 UTC).

What those addresses sit on

Usage type	Addresses	Share
Residential broadband	8,141,209	79.4%
Mobile network	1,368,798	13.3%
Gateway / NAT egress	467,034	4.6%
Datacenter	205,624	2.0%
Education network	47,673	0.5%
Unclassified	25,712	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 67 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.

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	965,520	9.4%
AS4837	721,836	7.0%
AS9808	345,459	3.4%
AS6057	257,614	2.5%
AS55836	217,058	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-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
2026-10-30	1,529,687	940,305
2026-10-31	1,442,095	886,256
2026-11-01	1,367,730	828,494

Volume eased week-over-week (−11% after the prior week's 10.5M window), while upstream sources sat at 67. The softer headline 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 stayed in a band roughly 1.37–1.53M 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 Ban on hosting or mobile: Network Attributes Aren't Risk Verdicts

IP99 — Sun, 01 Nov 2026 13:10:28 +0000

If your first IP rule is "block anything with hosting in the response," you will lock out Google Public DNS, most CDNs, CI runners, monitoring agents, and a large share of legitimate VPN egress — while still missing the residential proxy exits that dominate today's supply. IP99 by ThreatHunter returns both network attributes and risk signals in the same JSON. They look similar in an array. They are not the same thing.

This walkthrough stays on the free, no-key GET /v1/ip/{ip} endpoint. Live samples were captured on 2026-11-01 (UTC).

Two kinds of slug in `risk.signals`

IP99 lists up to ten slugs under risk.signals. Official docs split them:

Slug	Kind	Participates in score?
`proxy`, `vpn`, `dialup_pool`, `hijacked_proxy`, `osint`, `cloud_service`, `cloud_phone`	Risk observations	Yes (when evidence is fresh)
`crawler`	Benign crawler egress	No
`hosting`, `mobile`	Network attributes derived from scene	No

hosting means the address sits in datacenter / CDN / Anycast-style space. mobile means cellular. Neither is a proxy verdict. IP99's own copy is blunt: do not ban on hosting or mobile alone — that is how you cut whole clouds and whole carrier ranges. There is no Tor signal; do not invent one.

network.usage_type is the machine-readable scene code behind those attributes (IDC, CDN, DYN, MOB, GTW, EDU, …). Read it as context, not as guilt.

Example A: famous resolver, `hosting`, score 0

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

Captured ~2026-11-01 13:06 UTC:

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

usage_type: IDC and signals: ["hosting"] only say "this lives in hosting space." evidence_state: none with score 0 means IP99 holds no current verifiable risk evidence — not "safe," and not "block." The score measures freshness and strength of risk evidence; it is not the probability that an address is an attacker.

Example B: CDN edge, same pattern

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

Captured ~2026-11-01 13:07 UTC (abbreviated):

{
  "ip": "104.16.132.229",
  "evidence_state": "none",
  "network": { "asn": 13335, "usage_type": "CDN" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

CDN space is hosting-shaped. Partners, browsers, and APIs terminate here every day. A hosting-only rule treats Cloudflare (and peers) like a proxy farm.

Example C: residential scene with proxy-class evidence

Public demo address often used in IP99 docs (residential dial-up / proxy supply). Full address works in curl; tickets should mask the last octet.

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

Captured ~2026-11-01 13:06 UTC (last octet masked in the body):

{
  "ip": "27.22.66.x",
  "computed_at": "2026-11-01T13:06:56Z",
  "evidence_state": "active",
  "degraded": true,
  "geo": {
    "continent": "AS",
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Yicheng",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 7,
    "level": "low",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

usage_type: DYN is residential broadband — the opposite of a datacenter blocklist target — yet the risk side shows proxy / dialup_pool / hijacked_proxy with evidence_state: active. That is why network-type bans miss most of the problem: rotating residential supply lives on home and mobile ranges.

Note hijacked_proxy: the address holder is often a victim (malware turning a home router into exit capacity). Treat it as a reason for step-up checks, not an automatic account ban. Score here is low (7 / low) because evidence strength and freshness decay; active still means "act on the signal type," not "ignore because the number is small."

degraded: true appeared on this capture — some upstreams were unavailable. Official guidance: discount a degraded answer; do not pretend it is a full picture.

A policy order that respects the schema

IP99's documented read order is boring on purpose:

evidence_state — active (fresh enough to score), stale (seen before, window expired, score 0, weak feature only), none (never seen; coverage gap ≠ safe).
risk.score / risk.level — 0 = none, 1–29 low, 30–69 medium, 70–100 high.
risk.signals — branch by type: proxy-class vs crawler vs network attributes.
Ban scope — on Pulse, share_tier (T0–T3) decides whether an IP ban is one tenant or a building; the free endpoint does not expose share tier.
degraded — if present, widen uncertainty.

Concrete anti-patterns:

Ban every hosting or every MOB / mobile hit.
Treat score 0 as a clean bill of health without reading evidence_state.
Cache yesterday's label across users or sessions (store computed_at + evidence_state, not a permanent "bad IP" tag).
Equate usage_type: IDC with fraud; CI, VPN, and partners live there.

A small branch that matches the schema:

if "hosting" in signals or "mobile" in signals:
    record network_context  # do not block on this alone
if evidence_state == "active" and signals ∩ {proxy, vpn, dialup_pool, cloud_phone, ...}:
    step_up_or_limit()      # captcha / throttle / review — not "ban the building" by default
if evidence_state in ("stale", "none") and score == 0:
    do_not_mark_clean()

Try it without a key

Anonymous quota today (GET /v1/me): 500 lookups/day per client IP, 60/min, reset at midnight Asia/Shanghai. Responses also carry X-Daily-Limit, X-Daily-Remaining, and X-Daily-Reset. CORS is open (Access-Control-Allow-Origin: *), so a browser can call the endpoint directly; the quota still counts against the visitor's egress IP.

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

Same score shape is available as an MCP tool (ip_risk_lookup at https://ip99.com/mcp) and via the published OpenAPI document at https://ip99.com/openapi.json. Paid volume plans change quotas, not the free answer. Per-evidence rows, share_tier, and ?at= history sit on Pulse (professional).

Takeaway

hosting and mobile describe where an address sits. proxy, vpn, dialup_pool, and friends describe what it has been observed doing, with a clock. Block on the second class when evidence_state says the clock still matters; use the first class for routing and expectations. For field definitions and the free lookup, start at ip99.com.

Import IP99's OpenAPI Once: Postman, Codegen, and GPT Actions

IP99 — Sat, 31 Oct 2026 13:08:29 +0000

Most IP-risk vendors hand you a PDF and a support ticket. IP99 by ThreatHunter publishes an OpenAPI 3.1 document at a stable URL you can import the same way you import any other public API: Postman, Insomnia, openapi-generator, or a GPT Action. One file describes the free profile, the quota endpoint, and the professional Pulse path — so your clients, types, and agent tools stay in sync with the live service instead of a blog post you copied six months ago.

This is a practical import walkthrough. Every curl below runs without an API key. Live samples were captured on 2026-10-31 (UTC).

What the spec actually covers

curl -s https://ip99.com/openapi.json | head -c 200
# → {"openapi":"3.1.0","info":{"title":"IP99 IP risk and geolocation API",...

As of today the document advertises OpenAPI 3.1.0, title IP99 IP risk and geolocation API, version 1.0.0, server https://ip99.com, and three paths:

Path	What it is
`GET /v1/ip/{ip}`	Free risk + geo + network profile (key optional)
`GET /v1/me`	Your current tier and remaining quota
`GET /pulse/v1/ip/{ip}`	Same score with per-evidence detail (professional key)

Access-Control-Allow-Origin: * is set on the OpenAPI JSON itself, so browser-based importers and GPT Action validators can fetch it without a CORS proxy. Security schemes in the file are exactly what the human docs say: X-API-Key header or Authorization: Bearer, never a query string (?key= is rejected with HTTP 400 key_in_query).

The free endpoint is still the one you should try first:

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

Captured ~2026-10-31 13:05 UTC:

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

hosting here is a network attribute, not a risk verdict. Score 0 with evidence_state: none means "no current verifiable evidence," not "safe." Official copy is blunt about that; your generated client should expose evidence_state as a first-class field, not bury it under "extra."

Import into Postman (or Insomnia)

Copy https://ip99.com/openapi.json.
Postman: Import → Link → paste the URL → Import. Insomnia: Create → Import From → URL.
You get three requests. Open lookupIP (GET /v1/ip/{ip}), set ip to 8.8.8.8, send. No Authorization needed for anonymous quota.
Optional: add a collection variable apiKey and map it to the apiKey / bearer scheme when you create a free key in the console. Fields do not change with a key — only the quota counter does.

Anonymous allowance today (from GET /v1/me): 500 lookups/day per client IP, 60/min, resetting at midnight Asia/Shanghai. Sign in and self-create a key for a higher daily bucket; overseas self-serve Pro / Pro+ buys volume, not a different score. Per-item evidence rows, share_tier, and ?at= history sit on Pulse and need a professional key.

Generate a typed client

Any OpenAPI 3.1 generator that understands 3.1 will work. Example with the official CLI (install once, then pin the URL):

npx @openapitools/openapi-generator-cli generate \
  -i https://ip99.com/openapi.json \
  -g typescript-fetch \
  -o ./ip99-client

Or Python:

openapi-generator-cli generate \
  -i https://ip99.com/openapi.json \
  -g python \
  -o ./ip99-py

What you should assert in a smoke test after generation:

Response type includes evidence_state enum: active | stale | none.
risk.score is documented (and treated in app code) as freshness/strength of evidence, not "probability this visitor is an attacker."
risk.signals is an array of slugs; hosting / mobile describe the network and are not, by themselves, a ban reason.
Errors are { "error": { "code", "message" } } — branch on error.code, never on the prose in message.

A second live call, using IP99's documented demo address (mask the last octet of real customer IPs in tickets):

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

Same window:

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

Residential usage_type: DYN plus proxy-class signals is exactly why "ban all IDC ASN ranges" fails: the interesting exits often sit on home broadband. Official triage order: read evidence_state first, then signals, then score/level — and prefer step-up verification over hard-banning a whole building when the address may be shared.

Wire it as a GPT Action (or similar)

Custom GPTs / Actions that accept an OpenAPI URL can point at the same file. Practical checklist:

Schema URL: https://ip99.com/openapi.json (CORS already allows browser fetch).
Auth for free experiments: none. For production volume, header X-API-Key.
Restrict the Action to GET /v1/ip/{ip} (and maybe /v1/me) unless the agent truly has a professional Pulse key. Leaving Pulse in the Action without a key only produces 403 professional_required noise.
Prompt the model to report evidence_state and computed_at alongside the score. A stale or empty evidence state with score 0 must not be summarized as "clean IP."

If you want agents without a custom GPT, IP99 also exposes the same free profile as an MCP tool ip_risk_lookup at https://ip99.com/mcp — same fields as /v1/ip/{ip}. That path is covered in an earlier post; the OpenAPI file remains the right source of truth for HTTP clients and codegen.

Quotas, headers, and what not to invent

Every successful lookup can carry daily quota headers (X-Daily-Limit, X-Daily-Remaining, X-Daily-Reset). Prefer those (or GET /v1/me) over hard-coding numbers from an old article — allowances can change, and the response is authoritative for your tier.

Do not cache risk verdicts across sessions: the product thesis is that every answer is a judgement that expires. computed_at is part of what makes a decision auditable. Pulse's ?at= replay exists for chargeback-style "what did we know then?" questions; the free /v1/ip endpoint answers now only.

Also out of scope for this import guide (and for honest marketing): inventing customer logos, accuracy percentages, funding claims, or equating IP99's free profile with ThreatHunter's full enterprise datasets. IP99 is a ThreatHunter product; the free JSON you get from /v1/ip is exactly what the OpenAPI schema for that path describes — nothing more.

Try it

Import https://ip99.com/openapi.json.
Hit /v1/ip/8.8.8.8 with no key.
Branch your app on evidence_state before you trust a zero.

Human reference: https://ip99.com/api. Product home: https://ip99.com.

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.

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%

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

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.

DEV Community: IP99

Don't Ban on a Public List Alone: Reading osint on IP99

What osint is (and what it is not)

Why public listings go stale

Documented contrast: hosting without a listing vs listing plus proxy vs proxy without osint

What the weekly capture mix says

A practical branch (evidence_state first)

Try it

Serverless Exits Still Leave Fingerprints: Reading cloud_service on IP99

What cloud_service is (and what it is not)

Documented contrast: hosting attribute vs IDC proxy vs residential supply

What the weekly capture mix says

A practical branch (evidence_state first)

Try it

Is This IP a VPN? Reading the vpn Signal Without Blanket Blocks

What vpn is (and what it is not)

Documented contrast: hosting attribute vs datacenter proxy

What the weekly capture mix says

A practical branch (evidence_state first)

Try it

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

What those addresses sit on

Why 3.6% still is not "mostly datacenter"

Which networks show up most

Day-to-day shape

How to use this without over-blocking

Check one yourself

Don't Ban the Hijacked Exit: Reading hijacked_proxy Without Punishing Victims

What hijacked_proxy is (and is not)

Live contrast: clean hosting attribute vs leftover hijack tags

A practical branch for login and support

Try it

Score Zero Has Two Meanings: Branch on evidence_state First

What evidence_state actually means

Example A: score 0 + none (never seen as risk evidence)

Example B: score 0 + stale (same demo IP, different day)

The decision order (free /v1/ip)

Try it without a key

Takeaway

This Week's Proxy Exits: 10.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

Don't Ban on hosting or mobile: Network Attributes Aren't Risk Verdicts

Two kinds of slug in risk.signals

Example A: famous resolver, hosting, score 0

Example B: CDN edge, same pattern

Example C: residential scene with proxy-class evidence

A policy order that respects the schema

Try it without a key

Takeaway

Import IP99's OpenAPI Once: Postman, Codegen, and GPT Actions

What the spec actually covers

Import into Postman (or Insomnia)

Generate a typed client

Wire it as a GPT Action (or similar)

Quotas, headers, and what not to invent

Try it

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

What `osint` is (and what it is not)

What `cloud_service` is (and what it is not)

What `vpn` is (and what it is not)

What `hijacked_proxy` is (and is not)

What `evidence_state` actually means

Example A: score 0 + `none` (never seen as risk evidence)

Example B: score 0 + `stale` (same demo IP, different day)

The decision order (free `/v1/ip`)

Two kinds of slug in `risk.signals`

Example A: famous resolver, `hosting`, score 0