A competitor regularly visits your landing page from their office. The same bot hammers your link a hundred times a day. An affiliate network's tester checks the offer from the same server every time. For cases like these there is a simple and precise tool: an IP blacklist. Add the address, and it will never see anything but the neutral page again.
The simplicity is deceptive, though. IP blocking works great against fixed addresses and is nearly useless against anyone who changes them. Let's look at when an IP blacklist is really needed, how to write addresses and subnets correctly and where it does harm.
What is an IP blacklist
An IP blacklist is a list of addresses and ranges that are denied access to the offer in advance. In the context of a cloaker this is not a "ban" in the usual sense: the visitor gets no error but sees a White Page, an ordinary neutral page. So they never even learn they were filtered.
There are two kinds of lists:
| Your own list | The service's shared list | |
|---|---|---|
| Who maintains it | You | The protection system, automatically |
| Who ends up on it | Competitors, your devices, specific persistent bots | Addresses confidently caught automating |
| Where it applies | In your account | For every client of the service |
| When it grows | Manually, when you decide | As bots are detected |
Both are useful but solve different problems. The shared list covers mass known bots; your own covers your specific cases.
When to block an address by IP
Good candidates for your own blacklist:
- a competitor with a fixed address — an office, their own server, a static IP;
- your test devices, if you want to see exactly the White Page (for example, to check how it looks on a live flow);
- a server that polls your link regularly — a monitor, a scraper, someone else's script;
- addresses caught in click fraud — repeated clicks from one address, covered in detail in click fraud;
- a hosting subnet that bots come from, if you do not want to turn on blocking of all data centers in the flow.
When IP blocking will not help or will hurt
Mobile addresses
Mobile carriers send many subscribers out through shared addresses, and one subscriber keeps getting new ones. Block such an IP and you cut random real people, while the bot comes back a minute later from another address.
Dynamic residential addresses
Many home ISPs change the address on reconnect. Today it belongs to a bot, tomorrow to your buyer.
VPNs and proxies
Blocking individual VPN addresses is pointless: there are thousands of them. Against VPNs what works is not a list but detection by network and signals, covered in VPN, proxy and data center IPs, and how an address is assessed overall is covered in IP reputation explained.
Botnets and residential proxies
Here there are so many addresses, changing so fast, that a list cannot keep up. You need browser and behavior checks — see headless browsers and browser fingerprinting.
Tip. If you feel like adding more than a few dozen scattered addresses to the list, stop. Most likely the problem will be solved by configuring the flow's protection properly, not by a manual list.
IP addresses and subnets: how to write them
IPv4 and IPv6
An IPv4 address looks like 203.0.113.7, IPv6 like 2001:db8::1. Both types can be blocked, but remember mobile networks: IPv6 is very common there.
Subnets in CIDR notation
To block a range, use CIDR notation: an address and a mask length separated by a slash.
| Notation | What it means | Number of addresses (IPv4) |
|---|---|---|
203.0.113.7 |
a single address | 1 |
203.0.113.0/24 |
203.0.113.0 to 203.0.113.255 | 256 |
203.0.112.0/22 |
four consecutive /24 subnets | 1,024 |
198.51.0.0/16 |
every address starting with 198.51 | 65,536 |
The rule is simple: the smaller the number after the slash, the wider the range. A /16 subnet is already a whole chunk of an ISP, and it almost certainly has real users. For IPv6 the logic is the same, only each block holds orders of magnitude more addresses.
Where to get the address
From the visit log: every click has an IP, network and ISP. If lots of bots come from one network, look at its ASN — it may be better to block the whole network through audience rules than to list addresses.
Blacklist vs whitelist: which wins
An IP whitelist is the opposite tool: addresses that pass to the offer without checks. It is for your own tests, so you and your team can see the offer from work devices without fighting your own filter.
If an address is on both lists, you need to know which one wins. It makes more sense for the blacklist to win: you explicitly banned that address, and a stray whitelist entry should not override that.
The IP blacklist in ArtisanClo
ArtisanClo has both levels.
Your blacklist
Your own list of addresses that must never see the offer. It applies to all your flows and only in your account; it does not affect other clients.
- A visit from a listed address goes straight to the White Page, with no checks, trust score or warm-up. The reason in the log is "In your blacklist".
- The blacklist beats the whitelist: even if the address is on the flow's IP whitelist, it sees the White Page.
- The same goes for Shadow mode and Tracker mode: you banned the address yourself.
- Changes take effect immediately, from the next visit.
You can block an address right from the click log: next to the address in every row there is an icon — red to block, green to unblock. You can tick several rows and block them in one go; each action is confirmed in a window listing the addresses.
On the Blacklist page, addresses can be added one at a time with a note (for example "competitor") or as a list, one address per line, pasted straight from a spreadsheet. IPv4, IPv6 and subnets in CIDR notation are accepted; overly wide subnets that would cover whole regions of the internet are rejected. The list shows the date added, the author and the note.
The shared bot list
Automatic protection works separately. If an ad review service, a platform crawler or a program posing as a browser is confidently identified for any client, the address is remembered across the whole service, and its next visit to any flow gets the White Page straight away, with the reason "Known bot address". Real visitors on a questionable network, a VPN or without JavaScript are never added. An address caught automating for several clients at once ends up in the shared IP blacklist.
These addresses are not shown on your blacklist page, and you do not need to remove them. Only the flow's IP whitelist bypasses the shared list.
The whitelist
The IP whitelist is set on the last step of flow setup: IPv4 addresses and subnets, one per line. The Add my IP button appends the address you are working from. Whitelisted addresses pass to the offer without checks and without the per-IP click limit.
More on reading decision reasons in why a click went to the White Page, and the general flow setup order in how to set up a cloaker step by step.
Three scenarios from practice
Below are typical situations where a buyer reaches for IP blocking. The examples are illustrative.
A competitor checks your landing page every morning. The visit log shows the same residential or office ISP address, without an ad click ID, several times a day, always around nine in the morning. This is the ideal case for a blacklist: the address is stable, and after blocking the competitor sees the neutral page. Label the entry so you know where it came from a month later.
A hundred visits a day from addresses on one host. The addresses differ, but all come from one cloud provider's network. Listing them is pointless — tomorrow there will be others. It is better to turn on data center blocking in the flow or block that network by ASN in the audience rules.
Many rejections from mobile addresses of one carrier. The temptation to block the subnet is strong, but thousands of subscribers sit behind it. Find the cause first: it may be a social app's in-app browser tripping an overly strict check, and the problem is in the settings rather than in bots.
The common rule for all three: before blocking, look at the address in the log as a whole — network, ISP, device, click ID and decision reason. Blocking is justified when a single entity is behind the address. If a crowd is behind it, you need a different tool.
Practical rules for maintaining a blacklist
- Label your entries. A month later you will not remember why
203.0.113.42is blocked. A note saying "competitor, office" saves time. - Block narrowly. First the address, then a
/24, and only with certainty anything wider. - Do not block mobile addresses, except in very obvious cases.
- Review the list. Addresses change hands; what was a bot six months ago may be a home subscriber today.
- Do not replace protection settings with a list. If the log shows lots of different bots from data centers, turn on data center blocking rather than listing addresses.
- Do not forget yourself. If you added your own IP to the blacklist to check the White Page, remove it afterwards, or you will wonder why you cannot see the offer.
- Agree on rules in the team. If several people maintain the list, decide who adds addresses and by what rule. Otherwise in six months it will be full of entries nobody can explain, and removing them will feel risky.
The general logic of layered protection is in how to filter bot traffic. Which plans include which protection features is on the pricing page.
Summary
An IP blacklist is a precise tool against fixed addresses: competitors, your own test devices, persistent servers. Against mobile networks, VPNs and botnets it is powerless and can do harm, because addresses change and are shared between people. Keep your own list narrow and annotated, leave mass bots to the shared list and the flow's protection settings, and remember that an address you have banned should not get through even via the whitelist.
