How to Block an IP Address: Every Layer, Every Platform (2026 Guide)

Blocking an IP address means telling one specific system to refuse traffic from one specific network position. You can do it at your device firewall, your router, your web server, your CDN, or inside your application — and the layer you pick decides whether the block actually helps or quietly breaks something you needed. Most guides skip that decision entirely and jump straight to commands.

Here is the number that should shape every choice you make on this page. In Cloudflare's H1 2026 DDoS report, 90.60% of network-layer attacks ended in under ten minutes. By the time a human reads an alert, opens a config file, adds a rule and reloads the service, the attack is over and the address has moved on.

That does not make blocking useless. It makes blocking an architecture decision rather than an emergency reflex. This guide covers which layer to block at, whether to block a single address or a whole range, who you are likely to lock out by accident, and the cases where blocking is the wrong tool entirely.

Author: Robert Harrison OSINT & Network Utility Expert

The worst outage I ever helped unpick was self-inflicted. A team facing a scraping problem blocked a /16 at the edge, and inside four hours their payment processor's callback traffic was landing in the same range. Nobody connected the two. I spent an afternoon reading firewall counters to find it. Since then I ask one question before any IP block goes live: what else lives in this range?

My honest position is that blocking is overrated as a defence and underrated as a filter. It will not stop a determined attacker, who rotates addresses faster than you can add rules. It will cut noise, protect a login endpoint, and buy time. Treat a blocklist as housekeeping rather than security, and you will make far better decisions about what belongs on it.

What Does Blocking an IP Address Actually Do?

Blocking an IP address configures one system to drop or refuse connections originating from that address. It affects only the system holding the rule. Your web server rejecting an IP address does nothing about that address reaching your mail server, your SSH port, or any other host you own. Nothing is removed from the internet, nothing is reported anywhere, and the person behind the address is usually never told.

Two mechanics matter more than the syntax. A drop silently discards the packet and leaves the sender waiting for a timeout. A reject sends a refusal back, which is faster for the sender and reveals that something deliberately turned them away. Drop hides the rule; reject is politer to legitimate users who got caught by mistake.

Scale explains why this question comes up so often now. Cloudflare's H1 2026 DDoS Threat Report recorded 23.2 million network-layer attacks and 29.64 trillion HTTP DDoS requests between January and June 2026 — roughly 5,343 network-layer attacks every hour. Hostile traffic is now ordinary background conditions rather than an event.

Knowing what the action does still leaves the first real decision unmade, and getting it wrong is what wastes most people's afternoon.

Which Layer Should You Block At?

Block at the highest layer that still sees the traffic. Higher layers stop unwanted requests before they consume your bandwidth, your CPU, or your application logic. A CDN rule rejects a foreign request entirely; a rule inside WordPress rejects it only after PHP has already loaded and your database has already been queried. Same outcome for the visitor, wildly different cost to you.

The exception is visibility. Higher layers often hide the original address behind their own, so a server-level rule written after a CDN sits in front of it will match the CDN rather than the visitor. Anyone who has blocked an IP address in .htaccess and watched it keep arriving has met this problem.

That last row confuses people, so it earns a clarification. DNS filtering stops a device resolving a hostname, which prevents the connection from ever starting — a separate mechanism with separate strengths. IP address blocking and name blocking solve overlapping problems, and mature setups run both.

Layer chosen, the next decision determines your blast radius — and this is where people cause real damage.

Should You Block One IP, a Range, an ASN, or a Country?

Match the scope to how the traffic behaves. A single IP address suits a one-off nuisance, while a CIDR range (a block of consecutive addresses written as a prefix and a length, such as 203.0.113.0/24) suits an attacker rotating within one subnet. An ASN block covers an entire network operator, and a country block covers everything mapped to one nation. Each step up multiplies both your protection and your collateral damage.

Why ASN Often Beats Country

Blocking a hosting provider by its autonomous system number is usually sharper than blocking a country. Abuse concentrates in specific networks rather than spreading evenly across a nation, so an ASN rule removes the source while leaving that country's ordinary residential users reaching you normally. Country rules do the opposite: they punish millions of consumers and miss the attacker who rents a server elsewhere.

Both approaches need arithmetic before they need config. Convert your target into clean prefixes with a CIDR range calculator before pasting anything into a firewall, and if prefix notation is unfamiliar, our explainer on how subnet masks divide address space covers the underlying maths in plain terms.

Scope decided, the mechanics differ by platform — and the differences are larger than most tutorials admit.

How Do You Block an IP Address on Each Platform?

Every platform expresses the same idea with different syntax and different failure modes. Apache uses directives in configuration or .htaccess, and cPanel wraps that same mechanism in a screen labelled IP Address Deny Manager, while Nginx uses deny inside a server block. Linux offers iptables, nftables or ufw; Windows uses inbound rules with a scope tab; Cloudflare uses WAF custom rules. The concept transfers everywhere, and the mistakes do not.

The Cloudflare row deserves a footnote because guidance changed. Cloudflare now recommends custom rules rather than IP Access rules for both address-based and geography-based blocking, notes that blocking by country through IP Access rules requires an Enterprise plan, and caps each account at 50,000 IP Access rules. Plenty of tutorials still teach the older path.

Syntax is the easy part. The expensive part is discovering, days later, who else you removed.

Who Are You About to Block by Mistake?

Assume every IP address you block is shared until you prove otherwise. Mobile carriers place hundreds of subscribers behind one public IP address using carrier-grade NAT, and corporate networks present thousands of employees as a handful of addresses. Schools, hotels and hospitals do the same. Blocking one abusive visitor on a shared line removes everyone else standing behind it, and none of them will tell you.

Search crawlers are the other common casualty, and this one costs money. A user agent string is a claim, not proof — anything can call itself Googlebot. Blocking a range that contains the genuine crawler will deindex pages, while a fake crawler simply changes its label and continues. Verify before you block, never after.

Geo-blocking produces the most avoidable version of this failure. Organisations have blocked their own cloud services after discovering their hosting provider routed traffic through countries the allowlist never covered. The rule looked correct; the dependency map was wrong.

Suppose you avoid every one of those mistakes. Your block will still stop working, and understanding why changes how you use it.

Why Do Most IP Blocks Stop Working Within Hours?

IP addresses move, and attackers move faster than your maintenance schedule. Residential connections get a new IP address on reconnection, and mobile devices change addresses between towers. Attackers rent fresh servers by the hour, while residential proxy networks supply millions of ordinary home connections to route traffic through. A blocklist built by hand therefore ages out roughly as fast as one person can maintain it.

Speed makes it worse. Since 90.60% of network-layer attacks finish inside ten minutes, according to Cloudflare's H1 2026 figures, manual blocking arrives after the event nearly every time. Automated rules that add and expire entries on their own do useful work here; a person watching a dashboard does not.

Rotation Is the Business Model Now

Analysis of roughly four billion sessions between late 2025 and early 2026 found that 39% of unique sources hitting network edges came from residential connections, and 78% of them rotated away before any reputation system could flag them. Blocking assumes an IP address is a stable identifier. For a professional operation it is a consumable.

Temporary Blocks Beat Permanent Ones

The fix for rotation is not a longer list; it is a shorter memory. Automated tools watch logs for a pattern, add an entry when the pattern trips, then remove it after a set interval without anyone touching a config file. An hour is enough to break a brute-force loop. A permanent entry, by contrast, keeps punishing whoever inherits that address six months later.

Expiry also solves the maintenance problem that kills hand-built lists. A firewall carrying forty thousand stale entries costs lookup time on every packet and nobody remembers why half of them exist. Rules that clean up after themselves stay small enough to reason about, which matters more than raw coverage.

There is a second reason to prefer short bans. Blocking is loud. A sustained refusal tells a competent attacker exactly which detection threshold they crossed, and they will tune around it. A brief, quiet ban leaks far less information about how your defences work.

Forged source addresses add a further limit. Traffic can arrive claiming an address its sender never held, which our guide to detecting forged source addresses works through in detail. Filtering on a value the attacker controls has obvious limits.

None of that argues for doing nothing. It argues for picking the right instrument, and blocking is only one of four.

When Is Blocking the Wrong Tool?

Blocking is binary and permanent until you remove it, which makes it the wrong response to anything ambiguous. Rate limiting suits traffic that is welcome in small amounts and hostile in large ones, and challenges suit traffic you suspect but cannot confirm. Authentication suits anything sensitive enough that source address should never have been the control. Reach for an IP address block when the source is unambiguous and the volume is low.

Row four holds the strategic point. An allowlist denies everything except what you permit, which inverts the maths in your favour. You maintain a short list of known-good sources instead of an endless list of known-bad ones. That principle sits at the centre of never-trust-by-default network design, and for administrative endpoints it beats any blocklist you could build.

Volume explains why. Automated traffic reached 53% of all web traffic during 2025 in the Imperva 2026 Bad Bot Report, with bad bots at 40% and human visitors down to 47%. You cannot enumerate a majority.

Whichever instrument you choose, one step separates a working rule from an assumption — and most people skip it.

How Do You Verify a Block Worked and Undo It Safely?

Test from outside, not from your own connection. A rule that looks correct in a config file proves nothing until traffic from the blocked range actually fails to arrive. Equally important, every rule needs a written reason and a review date, because an unexplained entry from two years ago is the one nobody dares remove and the one quietly costing you customers.

Step five is the one experienced admins add after being burned once. Firewall logs tell you a rule fired; business metrics tell you whether it fired at the right people.

That is the full decision path, from layer to scope to verification. The summary below is what to keep.

The Short Version

Block at the highest layer that still sees real visitor IP addresses, and remember that a rule written below a CDN will match the CDN instead. Pick the narrowest scope the evidence supports, widening from a single address to a prefix only when logs show rotation. Blocking a hosting provider by ASN usually beats blocking a country, because abuse concentrates in networks rather than spreading evenly across nations.

Expect shared addresses everywhere. Carrier-grade NAT, corporate gateways and public networks mean one blocked IP address often represents hundreds of people. Verify any crawler before blocking it, since a user agent is a claim rather than proof, and deindexing your own pages is an expensive way to learn that.

Above all, treat blocking as housekeeping rather than defence. With 90.60% of network-layer attacks finishing inside ten minutes and automation now the majority of web traffic, hand-written rules will always arrive late. Automate expiry, prefer allowlists for anything administrative, and check what an IP address really is before you write anything — a quick look at the experience from the blocked visitor's side is a useful corrective before you press save.