---
title: "What Is IP Threat Intelligence? Signals and Scores Explained"
slug: "/guides/what-is-ip-threat-intelligence"
description: "IP threat intelligence shows whether an IP hides behind a VPN, proxy, Tor, or relay, sends bot traffic, or has a record of attacks. Learn to read each signal."
---

# What Is IP Threat Intelligence? How to Read Each Risk Signal

By [Anwar Ahmed](https://www.linkedin.com/in/anwar-ce/) Software Engineer

Posted on October 22, 2026 | 17 min read

![What Is IP Threat Intelligence? How to Read Each Risk Signal](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/10/Feature-image@1x.png)

IP threat intelligence is the evidence attached to an IP address that shows whether its traffic hides its origin, comes from automated tools, or has a record of attacks or spam. It usually arrives as a set of flags, each with its own evidence, plus a threat score that summarizes them.

Take a signup from an address in Berlin. Nothing about the location stands out. The threat data says otherwise: the address is a Tor exit, the server where Tor traffic leaves for the open internet, and it has a record of scanning other networks and sending spam. Each of those facts calls for its own response, and none of them would show up in a location lookup.

* * *

## TL;DR

IP threat intelligence works best when the threat score picks the action and the flags explain it. IPGeolocation.io documents four bands for its 0 to 100 score: 1 to 19 means allow with standard controls, 20 to 44 means combine with other signals, 45 to 79 means add friction, and 80 to 100 means block or review.

*   Weigh VPN, proxy, and bot detections by their confidence score and last-seen date before acting hard on them.
*   Privacy relays and corporate gateways put many legitimate people behind one address, so limit by account or session there, not by address.
*   Declared crawlers such as Googlebot carry a bot flag too; check whether a known operator stands behind a bot before treating it as hostile.
*   Report confirmed attacks to the network's registered abuse contact instead of only blocking them.

* * *

## What IP threat intelligence covers

Threat intelligence is raw threat data turned into context you can act on. The U.S. National Institute of Standards and Technology (NIST) [describes it](https://csrc.nist.gov/glossary/term/threat_intelligence) as threat information that has been processed "to provide the necessary context for decision-making processes." IP threat intelligence applies that idea to a single address.

One practical way to organize the signals is by the question each one answers. Some describe what the address is: the exit point of a VPN, a proxy, or Tor, a shared privacy relay, a company's security gateway, or a server in a hosting network. Others describe what has come from the address: automated traffic, attacks, or spam. A third kind tells you how far to trust the first two: how strong each detection is and when it was last seen.

![Diagram: what an address is, what came from it, and how sure and recent the evidence is feed one threat score](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/10/ip-threat-intelligence-signals.svg)

The table lists the common signals in that order, with the field IPGeolocation.io uses for each.

| Signal (field) | What it tells you | Who uses it legitimately | Sensible first response |
| --- | --- | --- | --- |
| VPN exit (`is_vpn`) | Traffic leaves through a VPN provider's server | Remote workers, travelers, privacy-minded users | Weigh the confidence score and any attack record; add friction on sensitive actions |
| Other proxies (`is_proxy` without `is_residential_proxy`) | A commercial proxy relays the traffic | Developers, testing and monitoring tools | Expected for APIs; unusual for consumer logins |
| Residential proxy (`is_residential_proxy`) | Traffic is routed through an address an internet provider assigned to a household | The household itself, which keeps using its own connection | Add friction on sensitive actions, weighted by confidence and last seen |
| Tor exit (`is_tor`) | Traffic leaves the Tor network at this address | Privacy-focused users, journalists, researchers | Challenge or restrict sensitive actions |
| Privacy relay (`is_relay`) | A service such as iCloud Private Relay hides the user's address but keeps an approximate location | Everyday users of the service | A lighter rule than for VPN traffic; don't block |
| Corporate gateway (`is_corporate_gateway`) | A company's security service forwards its employees' web traffic | That company's employees | Don't block; use per-account limits |
| Cloud hosting (`is_cloud_provider`) | The address belongs to a cloud or hosting provider | APIs, crawlers, monitoring | Normal for machine traffic; unusual for consumer logins and checkouts |
| Declared bot (`is_known_good_bot`) | Automation from a known, verifiable operator | Search engines, AI crawlers, uptime monitors | Apply your crawler policy |
| Undeclared bot (`is_bot` without `is_known_good_bot`) | Automation with no recognized operator | Some in-house scripts and tools | Challenge or rate limit |
| Known attacker (`is_known_attacker`) | The address has a history of attacks such as brute force or credential stuffing | Nobody on purpose, but everyone sharing the address inherits the record | Hard challenge or review on sensitive endpoints |
| Spam (`is_spam`) | Spam activity has been tied to the address | Nobody on purpose; shared addresses inherit this record too | Extra checks on forms, signups, and outgoing messages |

Few of these signals settle a decision alone. A VPN exit with a clean history and a VPN exit with an attack record are separate cases, even though both carry `is_vpn`.

* * *

## Anonymity signals: VPNs, proxies, and Tor

When someone connects through a VPN, a proxy, or Tor, your server never sees their own connection. It sees the address where the service hands the traffic back to the internet, the exit, and the exit is what threat data describes. Lists of the addresses users connect to, the entry points, won't match your logs for the same reason.

* * *

### 1. VPN exit addresses

Behind a VPN flag you'll find remote staff, people on hotel Wi-Fi, people who would rather not share their home address, and people who want to look as if they are somewhere else. The flag tells you which service carried the traffic, not which of those people you're dealing with, so treat it as a reason to read the rest of the evidence.

A VPN exit is a server a VPN provider runs to forward its customers' traffic. One reliable way to find exits is to go looking for them: connect through the service and record the addresses the traffic leaves from. IPGeolocation.io enumerates VPN networks this way continuously and returns the provider in `vpn_provider_names`, with a `vpn_confidence_score` and a `vpn_last_seen` date where available. Our explainer on [how VPN detection works](https://ipgeolocation.io/blog/what-is-vpn-detection-and-how-does-it-work) covers what enumeration catches and misses.

* * *

### 2. Commercial and residential proxies

Proxies split into two risk profiles. Commercial proxies run on servers, often in hosting networks, so the network type is a clue: few shoppers browse from a hosting company's [autonomous system](https://ipgeolocation.io/guides/what-is-an-asn).

Residential proxies route traffic through addresses that internet providers assigned to households. To a website the address looks like an ordinary home connection, so attackers who rent access to these networks slip past checks built for hosting networks. IPGeolocation.io flags these addresses with both `is_proxy` and `is_residential_proxy` and names the proxy network where it can. A real household also uses each of these addresses, which is why this flag deserves friction weighted by confidence and last seen rather than a block. The techniques behind it are in [why residential proxies are hard to detect](https://ipgeolocation.io/blog/how-residential-proxy-detection-works).

* * *

### 3. Tor exit nodes

A Tor exit node is the final relay in a Tor circuit. It hands the traffic to its destination, so the site sees the exit's address rather than the user's, as the [Tor Project explains in its guide to relay types](https://community.torproject.org/relay/types-of-relays/). Relay is Tor's word for its servers; Tor exits appear as `is_tor`, not under `is_relay`, which covers privacy relays such as iCloud Private Relay.

The Tor Project publishes its exits through a [bulk exit list built for site operators](https://check.torproject.org/api/bulk), with one caveat: the list covers exits that can reach a given server and port, port 80 by default, so a homegrown Tor check should export the list for its own server address and port.

The Berlin address in the opening scenario is 185.220.101.44, which was on that list when we checked it on October 20, 2026. IPGeolocation.io's response that day, trimmed to the fields that were set:

json

```json
{
  "ip": "185.220.101.44",
  "security": {
    "threat_score": 95,
    "is_tor": true,
    "is_anonymous": true,
    "is_known_attacker": true,
    "is_bot": true,
    "bot_type": "scanner",
    "is_known_good_bot": false,
    "bot_last_seen": "2026-09-14",
    "is_spam": true
  }
}
```

The Tor flag, which also sets `is_anonymous`, matches what the Tor Project lists. The rest is history: an attack record, scanning activity last seen in mid-September, and a spam record, which together put the address at 95. None of that accuses the person signing up. A Tor exit carries traffic for many people at once, so its record is the combined record of everyone who has used it, and the fair response is a check the person can pass rather than a dead end.

* * *

## Shared addresses: privacy relays and corporate gateways

Some addresses carry many legitimate people at once. Block one and you block all of them; rate-limit one and a whole office or neighborhood hits the limit together.

![Many users behind one privacy relay or corporate gateway address](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/10/shared-ip-addresses-relay-gateway-1.svg)

* * *

### 1. Privacy relays

Apple's iCloud Private Relay hides the user's address the way a VPN does, but it is built for privacy rather than for appearing somewhere else. Apple says the relay address [represents the user's coarse city-level location by default](https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/), that several Private Relay users in the same area may share it, and that its egress ranges are published so networks can recognize them.

IPGeolocation.io reports relays with their own flag, `is_relay`, and names the service in `relay_provider_name`, so relay users can get a lighter rule than VPN traffic. Because the location stays roughly right, a country check at checkout still works for them. Cloudflare WARP works differently; our comparison of [how iCloud Private Relay and Cloudflare WARP differ](https://ipgeolocation.io/blog/icloud-private-relay-vs-cloudflare-warp-explained) explains where.

* * *

### 2. Corporate gateways

Large companies send their employees' web traffic through cloud security services called secure web gateways, from vendors such as Zscaler or Netskope, so every employee reaches your site from the vendor's addresses. Blocking one of those addresses can lock out a whole company, and treating it as one user merges a workforce into a single visitor.

The Zscaler gateway sample in IPGeolocation.io's documentation, 87.58.66.106, returned `is_corporate_gateway` as true the same day, with the type `secure_web_gateway`, `is_anonymous` as false, and a threat score of 5. Its location was Dubai: the gateway's location, not necessarily the employee's, so leave gateway traffic out of location-mismatch checks. The gateway flag doesn't raise the score.

* * *

## Behavior signals: bots, known attackers, and spam

The second kind of signal records what has come from an address. It is what people usually mean by IP reputation: a history of automated traffic, attacks, or spam, built from honeypots and threat feeds.

* * *

### 1. Good bots and bad bots

Treat every bot flag as hostile and you'll turn away the crawlers that index your site. Some automation is declared: a known operator runs it and can be verified, often because the operator publishes the addresses its crawler uses. Search engines, AI companies' crawlers, and uptime monitors work this way. The rest is undeclared, from scrapers to credential stuffing tools.

In IPGeolocation.io's security database built on October 19, 2026, 6.9% of the ranges with bot activity belonged to declared, verifiable bots, and the other 93.1% was undeclared automation. We counted ranges where `is_bot` is true and checked how many also had `is_known_good_bot` set to true.

That declared minority needs a rule of its own. The API separates the two with `is_known_good_bot` and `bot_operator_name`, and `bot_type` says what the automation does, from `search_engine` and `ai_crawler` to `scraper` and `brute_force` ([the full list of bot types](https://ipgeolocation.io/documentation/ip-security-api.html)). A `scanner` can be a published research service or someone mapping targets, and `is_known_good_bot` tells them apart.

Large operators also split their crawlers by purpose. OpenAI, for example, [documents separate agents](https://developers.openai.com/api/docs/bots) for collecting training data (GPTBot), for search (OAI-SearchBot), and for fetching a page because a user asked (ChatGPT-User). Our `bot_type` values follow the same split: GPTBot is an `ai_crawler`, OAI-SearchBot a `search_engine`, and ChatGPT-User an `ai_assistant`.

The address 66.249.66.1, inside a range Google publishes for its crawlers, came back as a bot of the type `search_engine` operated by Google, with `is_known_good_bot` as true and a threat score of 15, in the lowest band.

![Decision flow using is_bot, is_known_good_bot, and bot_type to separate declared crawlers from attacks](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/10/good-bots-vs-bad-bots.svg)

* * *

### 2. How to verify a crawler that claims to be Googlebot

Anyone can put "Googlebot" in a user agent string, so the name proves nothing. [Google's verification steps](https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests) check the network instead:

1.  Run a reverse DNS lookup on the IP address from your logs, for example with the `host` command.
2.  Check that the domain name is in `googlebot.com`, `google.com`, or `googleusercontent.com`.
3.  Run a forward DNS lookup on that domain name.
4.  Confirm that it resolves to the same IP address you started with.

For 66.249.66.1, the two lookups look like this:

shell

```shell
host 66.249.66.1
# 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

host crawl-66-249-66-1.googlebot.com
# crawl-66-249-66-1.googlebot.com has address 66.249.66.1
```

The name sits in `googlebot.com` and the forward lookup returns the original address, so the request came from Google. For checks at scale, Google publishes its crawler ranges as JSON files, starting with [common-crawlers.json](https://developers.google.com/static/crawling/ipranges/common-crawlers.json) for Googlebot. The older `googlebot.json` address redirected there when we checked in October 2026, so update any script that still fetches it.

If you already look addresses up with IPGeolocation.io, `is_known_good_bot` and `bot_operator_name` answer the same question in that lookup for Googlebot and many other declared crawlers.

* * *

### 3. Known attackers and spam

Providers build attack and spam records by watching who misbehaves. Honeypots, servers that exist only to be probed, log every address that tries them, and threat feeds add what others have seen. IPGeolocation.io runs its own honeypots and adds curated threat feeds; the addresses they catch in brute-force attempts, credential stuffing, vulnerability scanning, and spam become `is_known_attacker` and `is_spam`. The attack bot types `exploit`, `credential_stuffing`, `brute_force`, and `worm` always arrive with `is_known_attacker` set. Our write-up on [how we collect detection evidence](https://ipgeolocation.io/blog/your-vpn-is-not-secret-how-we-detect-risky-hidden-ips) has the full method.

Behavior records age differently from infrastructure flags. An exit address stays flagged while a provider uses it and changes when the provider rotates addresses, which is what last-seen dates track. An attack record describes something that already happened, often through an address many people share.

* * *

## What is an IP threat score?

An IP threat score is a single number that summarizes the risk signals on an address, such as VPN or proxy use, bot activity, and attack history. One number lets you route traffic quickly, and the flags behind it tell you why it scored the way it did.

IPGeolocation.io's `threat_score` runs from 0, a clean address, to 100, and its documentation maps the score to four action bands:

*   **1 to 19, low observed risk:** allow with standard controls.
*   **20 to 44, use with context:** combine with other signals before acting.
*   **45 to 79, elevated risk:** add friction, such as a one-time code, a CAPTCHA, rate limits, or a review queue.
*   **80 to 100, high risk:** block, use a hard challenge, or route to manual review.

Treat the bands as a starting point and tune them to what is at stake: a password reset deserves a stricter threshold than reading an article. Logging scores and outcomes for a few weeks before you enforce anything shows you where your own thresholds belong.

![IP threat score bar from 0 to 100 with four action bands, plus confidence and last-seen as modifiers](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/10/ip-threat-score-bands.svg)

* * *

### 1. Confidence and last-seen dates

A confidence score from 0 to 100 says how strongly the evidence supports a VPN, proxy, or bot detection, and a last-seen date says when that activity was last observed. When a flag is false, its confidence score is 0, and a last-seen date stays empty when none is available. IPGeolocation.io's guidance is to let `threat_score` choose the action and the confidence scores decide how far to take it: inside the friction band, a high-confidence VPN detection seen this week might get a one-time code, and a weaker, older one a lighter check.

That is also our answer to the argument over single scores versus raw signals: use both. The score handles routine routing, and the flags let you explain a decision in an audit log and write separate rules for login, signup, and checkout.

* * *

## How to act on IP threat signals

Start with the address itself. Behind a load balancer or CDN, the connecting address belongs to that intermediary, so take the visitor's address only from a header your own proxy sets; our guide to [reading the real client IP address](https://ipgeolocation.io/guides/get-real-client-ip-address) covers each setup. Get that wrong and every signal in this guide describes the wrong machine.

From there, each flow has its own priorities:

| Flow | Signals to weigh first | Sensible default |
| --- | --- | --- |
| Login | Known attacker, Tor, high-confidence VPN or proxy | Step-up verification from 45; hard challenge or review from 80 |
| Signup | Residential proxy, Tor, undeclared bots, spam | Add verification from 45; review from 80 |
| Checkout | VPN or proxy, plus an IP country that doesn't match the billing country (skip the country check for gateway traffic) | Add friction from 45; decline only when several signals agree |
| Content and APIs | Declared vs undeclared bots, cloud hosting | Your crawler policy for declared bots; rate limits for undeclared ones |
| Security operations | Known attacker, `bot_type`, abuse contact data | Triage by bot type, then report confirmed abuse |

Here is that logic as a small Python function for Python 3.9 or later, using the `requests` library. It reads the API key from the environment, fails open when the lookup can't complete, carves out shared and declared traffic, applies the documented bands, and returns the flags behind each decision so you can log them.

python

```python
import logging
import os
from typing import List, Optional, Tuple

import requests

logger = logging.getLogger("ip_risk")

API_URL = "https://api.ipgeolocation.io/v3/security"  # needs a paid-plan key; free keys get HTTP 401
API_KEY = os.environ.get("IPGEOLOCATION_API_KEY")  # read from the environment, never hardcode it

FLAGS = ("is_tor", "is_vpn", "is_proxy", "is_residential_proxy", "is_relay",
         "is_known_attacker", "is_bot", "is_spam", "is_corporate_gateway", "is_known_good_bot")


def get_security(ip: str) -> Optional[dict]:
    """Fetch the security object for one IP; return None if the lookup can't complete."""
    if not API_KEY:
        logger.error("IPGEOLOCATION_API_KEY is not set")
        return None
    try:
        # A short timeout keeps a slow lookup from holding up a login.
        resp = requests.get(API_URL, params={"apiKey": API_KEY, "ip": ip}, timeout=2)
    except requests.RequestException as err:
        logger.warning("Security lookup failed for %s: %s", ip, type(err).__name__)
        return None
    if resp.status_code != 200:
        # Log the status only: the request URL carries the API key.
        logger.warning("Security lookup for %s returned HTTP %s", ip, resp.status_code)
        return None
    try:
        return resp.json().get("security")
    except ValueError:
        logger.warning("Security lookup for %s returned invalid JSON", ip)
        return None


def decide(security: Optional[dict]) -> Tuple[str, List[str]]:
    """Map a security object to an action plus the flags that explain it."""
    if not security:
        # Fail open: a failed lookup shouldn't lock out real customers.
        return "allow", ["lookup_unavailable"]
    reasons = [flag for flag in FLAGS if security.get(flag)]
    # Shared and declared traffic: the address is the wrong unit to act on.
    if security.get("is_corporate_gateway"):
        return "allow_with_account_limits", reasons
    if security.get("is_known_good_bot"):
        return "apply_crawler_policy", reasons
    score = security.get("threat_score") or 0
    if security.get("is_relay") and not security.get("is_known_attacker"):
        score = min(score, 44)  # example of a lighter rule for privacy relays; tune it
    if score >= 80:
        return "hard_challenge_or_review", reasons
    if score >= 45:
        return "add_friction", reasons
    if score >= 20:
        return "check_other_signals", reasons
    return "allow", reasons
```

Run on the responses for the three addresses in this guide, `decide()` returns:

| Address | Action | Flags returned for the log |
| --- | --- | --- |
| 185.220.101.44 (Tor exit) | `hard_challenge_or_review` | `is_tor`, `is_known_attacker`, `is_bot`, `is_spam` |
| 66.249.66.1 (Googlebot) | `apply_crawler_policy` | `is_bot`, `is_known_good_bot` |
| 87.58.66.106 (Zscaler gateway) | `allow_with_account_limits` | `is_corporate_gateway` |

The relay cap at 44 is our example of a lighter rule, not a documented setting, so tune it like the bands. A missing key, an HTTP error, or a timeout each returns `None`, which `decide()` turns into an allow with `lookup_unavailable` logged; for payouts and other high-value actions you might send those requests to review instead. The error log records the status code rather than the exception text, because the request URL includes your API key. Cache each result for a few hours: the security data refreshes at least twice a day, so a fresh lookup on every request adds latency without adding information.

![Trimmed security responses for a Tor exit, a Googlebot address, and a Zscaler corporate gateway](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/10/ip-security-api-real-lookups.svg)

Two habits round this out. Where you relax per-address limits for gateways and relays, replace them with per-account or per-session limits, and apply IPv6 limits to the /64 prefix rather than to single addresses, because one IPv6 user often holds a whole block. When an address has really attacked you, tell the network that can stop it: abuse contact data names the team each network registered for these reports, and the [IP Abuse Contact API](https://ipgeolocation.io/ip-abuse-contact-api.html) returns it for any address.

One rule we wouldn't bend: don't block a login on a VPN or proxy flag alone. Many of the people behind those flags are your customers. For analysts working through logs instead of live traffic, the same fields work as enrichment, and our guide on how to [enrich security logs with IP data](https://ipgeolocation.io/guides/what-is-ip-enrichment-and-why-logs-need-it) covers the pipeline.

* * *

## The limits every IP data provider shares

Some limits come from how the internet assigns and shares addresses, so no provider escapes them:

*   **New exits:** a VPN server or proxy that went live this morning hasn't been observed yet.
*   **Residential proxies:** they borrow real household addresses, so the address alone can look clean.
*   **Reassigned addresses:** an address that changes hands can carry an old record for a while.
*   **Shared addresses:** relays and gateways put many people behind one address.

IPGeolocation.io narrows these gaps instead of hiding them. Last-seen dates and confidence scores show how fresh and how strong each detection is, `is_residential_proxy` and the provider names cover proxies on household addresses, and the relay and gateway flags mark shared addresses so you can limit by account there instead. For exits too new for any list, [real-time proxy and VPN detection](https://ipgeolocation.io/real-time-proxy-and-vpn-detection.html) runs a small script in the visitor's browser that tests the live connection itself.

* * *

## IP threat intelligence from IPGeolocation.io

IPGeolocation.io's IP Security API returns the signals in this guide in one call: VPN, proxy, residential proxy, Tor, and relay detection with provider names, confidence scores, and last-seen dates where available; bot classification by type and operator; known-attacker and spam flags; cloud hosting and corporate gateway context; and a threat score from 0 to 100. With 27 fields in the security object, it is one of the most detailed security responses a single request can return, and that detail is what lets your rules go beyond yes or no: by provider, by confidence, and by recency.

Much of the evidence is first-hand. We enumerate VPN and proxy networks by connecting through them and run our own honeypots, then add curated threat feeds, and the security data refreshes at least twice every 24 hours. In our security database built on October 19, 2026, more than 110 VPN providers and more than 60 proxy providers appear by name, and exits we can't attribute to a provider are still flagged.

Security data also comes with the rest of an address's profile: one request to the unified IP Geolocation API can return geolocation, security (`include=security`), ASN, company, abuse contact data (`include=abuse`), time zone, and user agent data. The security bulk endpoint checks up to 50,000 IPs per request, the API has no rate limits, and the [IP Security Database](https://ipgeolocation.io/ip-security-database.html) delivers the same detection data as CSV or MMDB files, updated daily, for lookups on your own servers.

Security data is available on paid plans, and a free trial can be arranged through support. The [pricing page](https://ipgeolocation.io/pricing.html) compares plans and credits, and the [IP Security API](https://ipgeolocation.io/ip-security-api.html) page runs a lookup on any address in your browser.

## Frequently Asked Questions

### Is IP reputation the same as IP threat intelligence?

**Answer:** Not quite. IP reputation is an address's history of bad behavior, such as spam, scanning, or attacks, usually expressed as a score or a blocklist category. IP threat intelligence includes that history and adds what the address is: a VPN exit, a Tor exit, a privacy relay, or a corporate gateway.

### How can I check an IP address for malicious activity?

**Answer:** For an investigation, look the address up in an IP threat intelligence source and start with the behavior flags: known attacker, spam, and the bot type. In IPGeolocation.io's data, the attack bot types `exploit`, `credential_stuffing`, `brute_force`, and `worm` always come with `is_known_attacker` set to true, and the threat score summarizes the rest.

### What is an anonymous IP address?

**Answer:** An anonymous IP address hides the user's own address behind an intermediary: a VPN, a proxy, Tor, or a privacy relay. In IPGeolocation.io's security data, `is_anonymous` is true when any of those is detected. It stays false for corporate gateways, which the documentation treats as company infrastructure rather than an anonymity service.

### Should you block Tor exit nodes?

**Answer:** Not by default. A Tor exit carries traffic for many people at once, so a blanket block turns away legitimate visitors along with abusers. We would let Tor visitors read freely, challenge sensitive actions, and send them to review when the exit also carries an attack record. You can confirm any Tor exit against the Tor Project's own published list.

### What is the difference between good bots and bad bots?

**Answer:** The useful line is whether a known operator stands behind the bot. Declared bots such as Googlebot run under an operator you can verify, often through published address ranges. Undeclared automation, from scrapers to credential stuffing tools, has no accountable operator. In IPGeolocation.io's security database built on October 19, 2026, 6.9% of ranges with bot activity belonged to declared bots.

### Can IP threat intelligence identify the person behind a VPN?

**Answer:** No. It describes the address a request came from, which for VPN traffic is the provider's exit server, not the user's own connection. It can tell you that the exit belongs to a VPN, name the provider when it is known, and show how recently the address was seen on that network.

### Is IP threat intelligence data free?

**Answer:** Some of it is. Operators publish their own lists at no cost: the Tor Project lists its exits, Google its crawler ranges, and Apple its Private Relay egress ranges. IPGeolocation.io's security data needs a paid plan. The Free plan includes 1,000 credits per day for core geolocation, time zone, currency, country metadata, and basic ASN data; paid plans start at $19 per month for 150,000 credits on Starter, a standalone security lookup costs 2 credits, and a free trial is available through support.

### Related Guides

[![What Is IP Intelligence? The Five Layers of IP Data](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/10/what-is-ip-intelligence.png)](https://ipgeolocation.io/guides/what-is-ip-intelligence)

[What Is IP Intelligence? The Five Layers of IP Data](https://ipgeolocation.io/guides/what-is-ip-intelligence)

IP intelligence is the data attached to an IP address: location, threat signals, network, ownership, and abuse contacts. It explains where each layer comes from, why one IP's company and ASN can differ, and where the data ends.

Posted on October 20, 2026

By Abdul Mateen

[Read More](https://ipgeolocation.io/guides/what-is-ip-intelligence)

[![What Is a Regional Internet Registry, and What Does It Do?](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/06/how-ip-addresses-flow-from-iana-to-the-five-rirs-to-lirs-and-end-users.png)](https://ipgeolocation.io/guides/what-is-a-regional-internet-registry)

[What Is a Regional Internet Registry, and What Does It Do?](https://ipgeolocation.io/guides/what-is-a-regional-internet-registry)

A regional internet registry (RIR) hands out the IP addresses and AS numbers a region runs on. Here are the five RIRs, where each one operates, how IANA and LIRs fit around them, and why the answer shows up every time you run a WHOIS lookup.

Posted on June 25, 2026

By Mudassar Tariq

[Read More](https://ipgeolocation.io/guides/what-is-a-regional-internet-registry)

[![How to Get a Visitor's Real IP Address in Your Backend](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/06/how-to-get-the-real-client-ip-address-behind-a-proxy.png)](https://ipgeolocation.io/guides/get-real-client-ip-address)

[How to Get a Visitor's Real IP Address in Your Backend](https://ipgeolocation.io/guides/get-real-client-ip-address)

The real client IP is easy to get wrong behind a proxy or CDN. Here is how X-Forwarded-For, X-Real-IP, and CF-Connecting-IP work, which one to trust in each setup, and how to read the real IP without getting spoofed.

Posted on June 23, 2026

By Mudassar Tariq

[Read More](https://ipgeolocation.io/guides/get-real-client-ip-address)

[![What Is IP Enrichment and Why Logs Need It](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/05/what-is-ip-enrichment-and-why-logs-need-it-1.png)](https://ipgeolocation.io/guides/what-is-ip-enrichment-and-why-logs-need-it)

[What Is IP Enrichment and Why Logs Need It](https://ipgeolocation.io/guides/what-is-ip-enrichment-and-why-logs-need-it)

IP enrichment turns raw IP addresses in your server logs into useful context – geolocation, ASN, company, and threat data. This guide covers what enrichment adds, when to use an API vs. a local database, and how to implement both with production-ready Python and Node.js code.

Posted on May 20, 2026

By [Sheharyar Malik](https://www.linkedin.com/in/sheharyar-malik-haniel/)

[Read More](https://ipgeolocation.io/guides/what-is-ip-enrichment-and-why-logs-need-it)

[![What is an ISP and How is it Different From an ASN?](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/05/what-is-an-isp.png)](https://ipgeolocation.io/guides/what-is-an-isp-and-how-is-it-different-from-an-asn)

[What is an ISP and How is it Different From an ASN?](https://ipgeolocation.io/guides/what-is-an-isp-and-how-is-it-different-from-an-asn)

An ISP, or Internet Service Provider, is the company that gives you access to the internet and an ASN is a number that identifies one of the networks an ISP runs on the internet.

Posted on May 8, 2026

By [Sheharyar Malik](https://www.linkedin.com/in/sheharyar-malik-haniel/)

[Read More](https://ipgeolocation.io/guides/what-is-an-isp-and-how-is-it-different-from-an-asn)

[![What Is the Difference Between Unicast, Anycast, Multicast, and Broadcast?](https://blogs.ipgeolocation.io/blogs-site/content/images/2026/05/difference-bw-unicast-anycast-multicast-broadcast.png)](https://ipgeolocation.io/guides/unicast-anycast-multicast-and-broadcast-explained)

[What Is the Difference Between Unicast, Anycast, Multicast, and Broadcast?](https://ipgeolocation.io/guides/unicast-anycast-multicast-and-broadcast-explained)

Unicast, broadcast, multicast, and anycast are four ways network traffic reaches its destination. This guide covers how each one works, when to use it, and how anycast routing affects IP geolocation accuracy.

Posted on May 8, 2026

By [Sheharyar Malik](https://www.linkedin.com/in/sheharyar-malik-haniel/)

[Read More](https://ipgeolocation.io/guides/unicast-anycast-multicast-and-broadcast-explained)