My Geocode

Guides

Filter bot traffic using ASN and network data

· 3 min read · My Geocode · #ip-lookup#asn#bot-detection#security

Most real visitors connect from residential or mobile networks. Most automated traffic connects from data centers and cloud hosting providers. That difference shows up plainly in the asn and org fields on an IP lookup.

Getting network data

GET /v1/ip?ip=203.0.113.99
{
  "status": "ok",
  "ip": "203.0.113.99",
  "version": 4,
  "found": true,
  "country": "United States",
  "country_code": "US",
  "region": "Virginia",
  "city": "Ashburn",
  "postcode": "20147",
  "lat": 39.0438,
  "lon": -77.4874,
  "timezone": "America/New_York",
  "asn": 16509,
  "org": "Example Cloud Hosting"
}

Building a simple filter

Maintain a short list of organization name patterns or specific ASN numbers you associate with cloud hosting and known automation platforms, based on your own traffic history, and flag traffic from those networks for extra scrutiny, such as a CAPTCHA challenge or a lower trust score, rather than blocking outright. Legitimate uses of cloud IP ranges exist, including corporate VPNs and mobile carrier infrastructure, so this signal works best combined with behavioral signals rather than used alone.

A second signal: country mismatch

Combining the ASN check with the country_code field catches a different pattern. An account that claims to be based in one country but consistently signs in from a data center address registered in another is a stronger signal together than either fact is alone. Neither field on its own proves anything, since real customers travel and use VPNs for entirely ordinary reasons, but the combination is worth weighting more heavily in a scoring system than either check run in isolation.

Where this fits in a request

Run the ASN check at the point traffic first hits your application, such as a signup form or a login attempt, rather than after the fact, so the signal can actually influence what happens next. Cache the result for the length of a session, since an address's ASN does not change mid-session.

Handling returning visitors

A visitor who was scored once during signup and returns later from the same network address does not need a fresh lookup every time, since the asn and org fields for a given address remain stable across sessions. Cache the classification against the address itself, not just the session, so a known-safe residential address is not re-evaluated on every single future visit either.

A mistake worth avoiding

Blocking every request from a recognized hosting or cloud ASN outright, rather than scoring it, shuts out a real slice of legitimate traffic along with the automated traffic you actually meant to stop. Corporate VPN exits, some mobile carriers, and privacy-focused browsers all route through infrastructure that can register the same way a hosting provider does. Use the ASN and org fields as one input into a scoring or challenge decision, not as an automatic block rule on their own.

What it costs

One lookup per new session, cached afterward, is one request per visitor rather than one per request they make. On a site processing meaningful signup or login volume, this stays inside the 2,500 free requests a day included with every key for moderate traffic, and moves onto prepaid credit or an Unlimited key once volume grows past that.

Network origin is one signal among several, not a verdict on its own, but it is a cheap one to add to a signup or login flow. The IPv4 lookup docs and IPv6 lookup docs describe every field the endpoint returns.

More in Guides