What IP Access Rules are for, and what they are not
Every chat deployment eventually meets a visitor it does not want. Someone opens the widget twelve times an hour to abuse whoever picks it up. A competitor parks on the pricing page and asks the same questions from a rotating cast of names. A script hammers the offline form with link spam. The reasonable instinct is to block them, and the dashboard has a page for exactly that.
In the dashboard it is called IP Access Rules, and the page describes itself in one line: block or allow IP addresses and ranges to control who can access your live chat. By default the rule list is empty, which means there are no restrictions at all — an empty list is the normal, healthy state for most sites, and adding your first rule should feel like a deliberate act rather than routine housekeeping.
Before going further it is worth being clear about what this feature is, because the name invites a misreading. It is a nuisance-reduction tool, not a security control. It works on the network address a request appears to come from, and that address is neither stable nor secret nor hard to change. Anyone who wants to get past it can, with a phone hotspot and no technical knowledge whatsoever. Use it to make a persistent nuisance expensive; never use it as the thing standing between a determined attacker and something valuable.
A rule is an address expression plus an action, and the action is either Deny or Allow. The expression box is more flexible than it first appears, and the dashboard documents the syntax on the page itself:
192.168.1.20 — a single address.192.168. — a prefix. Trailing parts are filled in with wildcards, so this becomes 192.168.*.*. The box rewrites what you typed into the expanded form when it saves, which is a useful confirmation that it understood you.192.168.1.0-192.168.1.255 — a range, written with a hyphen.!192.168. — an exclusion, written with a leading exclamation mark.192.168.1.10|192.168.1.20 — several expressions in one rule, where the vertical bar means or.
Two limits are worth knowing before you start, because both are things an administrator will reasonably try first and both are rejected.
CIDR notation is not supported. If you paste 192.168.1.0/24 — the way network ranges are written nearly everywhere else — the rule will not save. Express the same range with a hyphen or a wildcard instead. This trips up exactly the people most comfortable with networking, because it is the notation they reach for automatically.
IPv6 addresses cannot be entered as rules. The expression format is four dot-separated numbers, and nothing else. This has a consequence that goes well beyond data entry, and it is covered further down.
What a blocked visitor actually sees
This is the part most worth understanding before you add a rule, because it is not what most people picture.
A blocked visitor does not see a message explaining that they have been blocked. They do not see an error. The widget simply does not appear, or reports that nobody is available. From their side, your site looks like a site that has no live chat, or has chat that is currently unstaffed.
The AI assistant is switched off for that visitor too, deliberately: someone you have decided to keep out of your chat should not be quietly handed to the bot instead. Blocking means blocking the whole surface, not downgrading the visitor to a cheaper channel.
The silence cuts both ways. It is the right behaviour for a nuisance, who gets no feedback to react to and no confirmation that they have been noticed. It is a serious problem for a false positive. If you block an office range and a real customer sits inside it, that customer will never be told why chat vanished, and you will never receive the complaint that would tell you the rule was wrong. A bad IP rule is close to invisible from both ends, which is the strongest argument for keeping the list short and documented.
The same list your agents are already writing to
There is a second door into this feature, and teams routinely discover it by accident.
When an agent uses the ban action on a visitor in the agent console, that does not create a separate, temporary, console-only block. It writes a Deny rule into the very same list the dashboard page shows. The console has a couple of sensible guards of its own — it refuses to ban the local loopback address, and it refuses to ban an address that currently has a console connection open, which stops an agent banning the office and locking out the team — but the result is a permanent rule that will still be there in a year.
The practical consequence: if your IP rules list has entries nobody remembers adding, the answer is usually that an agent banned somebody during a bad afternoon eighteen months ago. Those bans do not expire on their own. Reviewing the list periodically is not tidiness, it is the only mechanism by which a heat-of-the-moment decision ever gets revisited.
Where IP rules quietly stop applying
Two situations cause a rule to have no effect, and neither announces itself.
Visitors arriving over IPv6. Rules are written in the four-number IPv4 format, so an IPv6 visitor cannot match one. Rather than guess, the product treats an address it cannot parse as permitted: the visitor sees chat normally. A share of consumer traffic — on some mobile networks, a large share — arrives this way, so a Deny rule aimed at a specific person may simply not apply the next time they connect from their phone.
Visitors behind several proxies. When a request has passed through a chain of proxies or a CDN, the forwarded address can arrive in a form the parser will not accept, and the same fail-open rule applies.
Failing open is the right default. The alternative — treating an unparseable address as a match — would mean a single Deny rule blocking every visitor whose address could not be read, which is a far worse failure than letting one nuisance through. But it does mean the honest description of this feature is that it reliably blocks the specific IPv4 addresses you name, and makes no promise about anyone else. Plan around that rather than being surprised by it.
Rules worth keeping, and rules worth deleting
A short discipline keeps this page useful instead of dangerous.
Write down why. The rule list stores an address and an action, not a reason. Keep the reasons somewhere your team can read — a line in your operations notes with the date and the incident is enough. A rule with no recorded reason cannot be safely removed, so it stays forever by default.
Prefer the narrowest expression that solves the problem. A single address for a single nuisance. Reach for a wildcard or a range only when the behaviour genuinely comes from a range, and remember that ranges belonging to consumer internet providers are shared by thousands of unrelated people.
Set a review date. Twice a year, read the whole list and delete anything whose reason has expired. Most entries are responses to a specific person having a specific bad week, and that person stopped visiting long ago.
Do not use it to enforce business rules. If the goal is to stop serving a country, or to hide chat from visitors you cannot help, there is a separate feature built for that and it works on better signals than raw addresses. Blocking geography one address range at a time is a job with no end.
What to measure
This feature is unusually easy to get wrong silently, so the measurements that matter are the ones that would reveal a mistake.
The size of the list over time. It should be roughly flat. A list that only grows is a list nobody reviews, and every entry is a small permanent risk of turning away a real customer.
Chat volume after you add a range. Add a wildcard or a range rule, then compare chat starts for the following week against the week before. A visible drop means the range was wider than the problem.
Whether the nuisance actually stopped. If the abusive chats continue at the same rate after a block, the rule is not applying — usually one of the two fail-open cases above — and the answer is a different control, not a bigger range.
How old the oldest rule is. If the answer is measured in years and nobody can say what it is for, you have found your next deletion.
IP rules judge where a request came from. There is a second layer that judges what was written, described in the filter that rejects spam before it becomes a chat, including why it refuses visibly instead of silently dropping.