> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.pixalate.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.pixalate.com/_mcp/server.

# IP block lists (IPv4 and IPv6)

> Pixalate's IPv4 and IPv6 IP block lists, with update cadence, file names, schema, probability thresholds and how to apply them pre-bid, including X-Forwarded-For handling.

The IP block lists contain IP addresses that Pixalate has linked to malicious or compromised devices. Use them to block, or alert on, bid requests and other traffic from those addresses before you bid or serve.

Each IP comes with a fraud type and a probability from 0.5 to 1, so you choose how strict to be. There are two separate lists: one for IPv4 and one for IPv6.

## What's in the lists

An IP is added when Pixalate sees suspicious activity from it, and only once that activity is statistically significant. Listed IPs can belong to data centers, bad proxies, infected machines on home or cable connections, or organizations. They aren't necessarily part of a botnet.

* **Proxies and Tor.** Tor and proxy IPs are included in these lists, for example under the `proxy` fraud type. Tor IPs appear less often because there are very few of them.
* **`highriskapp`.** This fraud type marks an IP that generates high volumes on one or more high-risk apps, meaning apps blocked for high invalid traffic (IVT) rates.

For the meaning of each fraud type, see [Reported Invalid Traffic (IVT) Types](/analytics/ivt-types).

### Why there are two lists

IPv4 and IPv6 need separate integrations: the address formats differ, and you may see each type in a different place in your stack. The lists are also built independently. One IPv4 address can sit in front of many IPv6 addresses, so an IPv4 address with lots of good traffic may stay off the IPv4 list while some of its IPv6 addresses are listed.

An IPv4 address is often shared by a whole household or a cell tower, so blocking it also blocks good traffic. IPv6 addresses are more granular, which lets you block only the bad devices. Use both lists while IPv4 and IPv6 coexist.

Pixalate collects both the IPv4 and the IPv6 address (when available) for each ad transaction, so each list also informs the other.

## At a glance

|                | IPv4 list                            | IPv6 list                                  |
| -------------- | ------------------------------------ | ------------------------------------------ |
| Update cadence | Hourly                               | Twice a day                                |
| File format    | CSV                                  | CSV                                        |
| File name      | `GenericIPBlacklisting_YYYYMMDD.csv` | `GenericIPv6Blacklisting_YYYYMMDD.csv`     |
| Columns        | `ip`, `fraudType`, `probability`     | `ip`, `ipType`, `fraudType`, `probability` |
| File size      | Up to 1 GB                           | Up to 1 GB                                 |

The file name carries a date only, not a time or version, and a newer file can reuse an earlier file's name and replace it. Don't use the file name to find the newest file; check its last-modified time instead. See [Delivery and integration](/data-feeds/delivery).

## Schema

| Column        | Type   | Description                                                                                                                               |
| ------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `ip`          | string | The IP address that has shown suspicious traffic characteristics, is potentially malicious, or is registered as a data center IP.         |
| `ipType`      | string | **IPv6 list only.** The type of the IPv6 address, usually denoting its usage and infrastructure.                                          |
| `fraudType`   | string | The name of the IVT type linked to the IP, for example `datacenter`. See [Reported Invalid Traffic (IVT) Types](/analytics/ivt-types).    |
| `probability` | float  | How likely it is that the IP is linked to this fraud type, from 0.5 to 1. For example, 0.7 means a 70% probability. Higher means riskier. |

Example IPv4 rows (made-up values):

```csv
198.51.100.23,datacenter,1.0
203.0.113.45,proxy,0.82
192.0.2.117,highriskapp,0.64
```

Example IPv6 rows (made-up values; `<ipType>` stands in for the type value):

```csv
2001:db8:5c1::17,<ipType>,proxy,0.91
2001:db8:a40:3::2,<ipType>,datacenter,1.0
```

## Choose a probability threshold

Every listed IP has a probability of at least 0.5, calculated by Pixalate's machine learning models. You decide where to set your threshold, based on the quality and scale of your supply. As a general guide:

| Threshold                  | What you filter out                                                                    |
| -------------------------- | -------------------------------------------------------------------------------------- |
| Probability = 1            | Only the worst offenders (deterministic).                                              |
| Probability ≥ 0.90         | Traffic that is fraudulent beyond reasonable doubt.                                    |
| 0.75 ≤ probability \< 0.90 | Traffic with clear and convincing evidence of fraud.                                   |
| 0.5 ≤ probability \< 0.75  | Traffic that is more likely than not to be fraudulent (preponderance of the evidence). |

Lowering the threshold can reduce the number of impressions you deliver. Each time you change it, check the effect on impression delivery.

## Apply the lists pre-bid

1. Load the latest IPv4 and IPv6 files on the servers that make your bid or serving decisions.
2. For each request, find the IP addresses involved (see [Handle X-Forwarded-For](#handle-x-forwarded-for)).
3. Look up each IP in the list for its address family. If it's listed at or above your threshold, block the request.

Use the IP lists alongside the [user-agent feed](/data-feeds/user-agents), and block a request if **either** its IP **or** its user agent is listed.

## Check for new files

The IPv4 list updates hourly. Poll for it like this:

* Start checking at the top of the hour.
* Check every 15 minutes.
* Download only when a new file is available, then stop checking.
* Start again at the next hour.

The IPv6 list updates twice a day. For access, file locations and how to read a file's last-modified time, see [Delivery and integration](/data-feeds/delivery).

## Handle X-Forwarded-For

This matters most for the `proxy`, `datacenterProxy`, `IPObfuscation` and `MaskedIP` IVT types.

When traffic passes through a proxy, gateway or peer-to-peer connection, the de facto standard `X-Forwarded-For` header lists the IP addresses involved. In this example, a client at 203.0.113.10 reaches you through a proxy at 198.51.100.20:

```http
Source IP: 198.51.100.20
X-Forwarded-For: 203.0.113.10, 198.51.100.20
```

#### When the X-Forwarded-For header is present

Use the leftmost IP in the header (203.0.113.10 in the example) as the client IP. If it's on the block list, filter the request according to your threshold.

Also check every other IP in the header, and filter the request if any of them is listed, even when the client IP is clean. Flagged proxy IPs most often have the `proxy` fraud type, but can also appear as `datacenterProxy`, `IPObfuscation` or `MaskedIP`.

#### When the X-Forwarded-For header is absent

Use the source IP of the transaction (198.51.100.20 in the example), match it against the block list and filter according to your threshold.

#### When you can't see the HTTP headers

If you aren't a direct party to the transaction, ask your partners to pass you this information for every transaction. Your IP filtering is more effective with it.

## Handle a missing or zero last octet

Some requests arrive with the last octet of the IPv4 address removed, and a small number of IPs in the IP and data center feeds end in `.0`. In both cases the aim is usually to hide the true IP from downstream partners. You can:

* Use other feeds, such as the [mobile](/data-feeds/mobile-device-ids) and [CTV](/data-feeds/ctv-device-ids) device ID feeds or the app block lists. A device ID can still catch a source of IVT whose IP has been masked.
* Apply frequency caps per IP for residential IPs.
* Work with trusted partners and publishers.

A last octet of `0` doesn't on its own indicate invalid traffic. If you pass IPs on and the last octet isn't available, Pixalate recommends setting it to `0` rather than leaving it blank.

## Related

#### [Data center feeds](/data-feeds/data-center)

Weekly IPv4 and IPv6 CIDR ranges of hosting and cloud providers.

#### [Proxy gateway reference list](/data-feeds/proxy-gateway)

How many users sit behind a gateway IP. A reference list, not a block list.

#### [User-agent feed](/data-feeds/user-agents)

Bot user agents. Use with the IP lists in OR logic.

#### [Delivery and integration](/data-feeds/delivery)

Access, file locations and polling for every feed.