Is This IP in Your CIDR Range?
And Which Rule Actually Fires

How Does a CIDR Block Decide What Belongs to It?

By counting leading bits. The number after the slash is how many bits at the front are fixed; everything after them is free. An address belongs to the block when those fixed bits are identical. That is the whole membership test.

It does not change with what the list is for. An allowlist, a denylist, or the thing your router still calls a whitelist — same arithmetic, opposite consequence.

203.0.113.0/24 fixes the first 24 bits, which is the first three octets. Any address starting 203.0.113. is inside it and nothing else is. That is the whole rule, and it is why /24 and the subnet mask 255.255.255.0 mean the same thing — both say the same 24 bits are fixed.

Where it stops being obvious is when the prefix does not land on an octet boundary. 203.0.113.64/26 fixes 26 bits, so it covers .64 through .127 and nothing outside that. Read quickly it looks like it covers the whole last octet. It covers a quarter of it.

Order is part of the answer

An address can sit inside several of your blocks at once. Every other checker reports that as a list of matches, which is arithmetically true and practically useless, because almost nothing evaluates a rule list as a set.

iptables and nftables walk a chain top to bottom and stop at the first match. nginx reads its allow and deny directives the same way. Cloud firewalls evaluate by priority and stop. Most WAF rule sets and router ACLs do too. If an address hits your third rule and your seventh, rule seven never runs — and if rule seven was the one with the tighter port restriction, you have a problem that a list of matches will not show you.

So the results here lead with the first match, in the order you pasted your rules, and mention the others underneath as context rather than as answers.

Which of Your Rules Can Never Match Anything?

The ones sitting inside an earlier block. They read as deliberate and they do nothing.

Rule three looks like somebody carefully permitted a subnet. Nothing reaches it, because rule one already matched everything it covers. Removing it would not change what the firewall does — which is the textbook definition of a shadowed rule, and the reason it is worth clearing out rather than worth panicking about.

The version that actually costs you something

Now change one word.

Somebody wrote that deny for a reason. It sits in the config where anyone reviewing it will read it as protection. It has never once executed, and the host it names has full access.

This is the failure the industry writes about, and the symptom is specific enough to check for directly: the hit counter on the deny rule stays at zero while the counter on the broad allow above it climbs. You add a rule to block something, connections keep succeeding, and nothing in the config looks wrong.

Shadowing is one of three rule conflicts

The literature groups them together and the distinction is worth having, because the fix differs.

• Shadowed — an earlier rule matches everything this one would. It never runs. This is what the checker finds.
• Redundant — a later rule matches the same traffic with the same action. It runs sometimes and changes nothing when it does. Harmless, and worth deleting for the same reason clutter always is.
• Overly permissive — a rule that is correct but far wider than it needs to be. Nothing detects this from the addresses alone; it needs traffic data, which is why cloud providers only surface it after logging is switched on.

A conflict in the strict sense is two rules with opposite actions covering the same traffic. Order decides which wins, and if the order is wrong the config says one thing and the firewall does another.

How to fix one

Two options, and the right one depends on what you meant.

• Move the specific rule above the broad one. Specific denies belong above broad permits. This is the fix in almost every case and it is the standard advice in every ACL review checklist.
• Narrow the broad rule so it no longer covers the exception. More work, and the right answer when the broad rule was too generous to begin with.
• Delete the shadowed rule — but only once you are sure it was never meant to do anything. Deleting rules on a tool's say-so is how outages happen.

This is trivial to see in three lines and impossible to see in forty, which is why the checker looks on every run and reports what it finds whether or not you asked. To compare your blocks against each other rather than against an address — duplicates, containment, adjacency and what the list merges down to — the CIDR overlap checker does that side. Nothing warns you otherwise: the config loads, the firewall starts, and the rule simply never fires.

Sorting a rule list numerically makes the pattern much easier to read, since every broad block lands directly above the narrower ones inside it. The IP sorter handles that, including CIDR blocks ordered by network then prefix length.