cPanel IP Blocker: Block or Allow Specific IP Addresses

If someone's hammering your contact form, scraping your pricing page, or you just need to lock a staging site down to your office IP, cPanel has a built-in tool for that: IP Blocker (sometimes labeled IP Deny Manager on older themes). It's simple, it's free, and it's also frequently misunderstood — people expect it to whitelist traffic, block bots hiding behind Cloudflare, or survive a CDN, and it does none of those by design. Here's what it actually does, how to use it correctly, and where it falls over.

What cPanel's IP Blocker Actually Does

IP Blocker lives under cPanel > Security > IP Blocker. When you add an address or range, cPanel doesn't touch your server firewall — it writes a deny rule straight into the .htaccess file at the root of your account (or the domain's document root, depending on how your hosting is set up). On Apache, that means every request gets checked against Apache's own access-control logic before PHP or WordPress ever loads.

That's an important distinction from two other things people confuse it with:

If you're on shared hosting, you only have access to IP Blocker — CSF is a WHM/root-level tool. If you manage your own VPS, CSF is the better place to block an IP for good, because it stops the connection before Apache spends any resources on it.

How to Block an IP Address in cPanel

1. Log in to cPanel and open Security > IP Blocker.
2. Under "Add an IP Address or Range," enter the address. You can use a single IP (203.0.113.5), a range (203.0.113.5-203.0.113.20), or CIDR notation (203.0.113.0/24).
3. Click Add. cPanel confirms the entry and it takes effect immediately — no restart needed.
4. To remove a block later, scroll to the "Currently Blocked IP Addresses or Ranges" list and click Delete next to the entry.

Behind the scenes, that single click drops a block like this into your account's .htaccess:

<Limit GET POST PUT>
order allow,deny
deny from 203.0.113.5
allow from all
</Limit>

On newer EasyApache 4 configs you might instead see the Apache 2.4 syntax:

<RequireAll>
  Require all granted
  Require not ip 203.0.113.5
</RequireAll>

Either way, the effect is the same: that IP gets a 403 Forbidden on every request to that account, before your CMS or app even runs.

The Whitelist Question: "Can I Allow Only My IP?"

This is the most common support ticket around this feature — people want to lock a staging site or wp-admin down to a handful of trusted IPs, and they assume IP Blocker does that in reverse. It doesn't; it's deny-only. To allow-list, you need to write the .htaccess rule yourself (or through Password Protect Directories combined with an IP check), something like:

<RequireAny>
  Require ip 203.0.113.5
  Require ip 198.51.100.0/24
</RequireAny>

Drop that inside a <Directory>-style block or directly in the target folder's .htaccess via File Manager, and everyone outside those ranges gets a 403. It's a good way to lock down /wp-admin/ or a staging subdomain without a plugin.

Why the Block Sometimes "Doesn't Work"

Symptom: you block an IP, the abuse continues, and IP Blocker looks broken.

Cause 1 — Cloudflare or another CDN/proxy is in front of your site. Once traffic goes through Cloudflare, every request that reaches your server comes from Cloudflare's IPs, not the visitor's. Blocking the visitor's real IP in cPanel does nothing, because Apache never sees it — it sees Cloudflare. You need to block that visitor in Cloudflare (Security > WAF > IP Access Rules) instead.

Cause 2 — the abuser is rotating IPs. Botnets and scraper farms rarely sit on one address for long. If you're playing whack-a-mole with individual IPs, block by CIDR range where it's safe to do so, or move the fight to something pattern-based like ModSecurity or Cloudflare's bot-management rules.

Cause 3 — you're on LiteSpeed and caching is serving stale pages. LiteSpeed honors .htaccess deny rules, but if LSCache had already cached a page for that visitor before the block was added, a cached hit can occasionally slip through until the cache clears. Purge the cache after adding a block if you don't see it take effect immediately.

Locked Yourself Out

Symptom: you added a range to "clean up" a list of bad IPs and now your own office or home connection gets a 403 on the whole site.

Fix: the fastest way back in is through File Manager (via WHM if you're a reseller/root, or ask your host to pull the file) — open the account's root .htaccess and delete the <Limit> or <RequireAll> block that references your IP. If you can't reach cPanel at all because the login itself is blocked, you'll need SSH or FTP access to edit the file directly, or your host's support to remove the entry from their end.

To avoid this next time, check your current public IP (search "what is my ip") before entering ranges, and never block a /16 or wider CIDR unless you're certain what's in it — ISPs frequently share large blocks between residential and business customers.

IP Blocker Is Missing From cPanel

Symptom: Security section doesn't show IP Blocker at all.

Cause: it's a feature that hosts can disable per package in WHM's Feature Manager, and on CloudLinux servers it can also be hidden if the account is suspended or the reseller package restricts it.

Fix: if you're the account owner, ask your host to confirm the feature is enabled for your package. On Getwebup accounts it's on by default — if it's missing, open a ticket and we'll check the feature list on your package.

Prevention

• Use IP Blocker for quick, targeted, single-site blocks — not as your primary security layer.
• For server-wide or persistent abuse, push the block up to CSF (WHM) or your CDN/WAF, where it's enforced before Apache spends resources on the request.
• Keep a note (even a plain text file) of why each entry was added and when — lists that grow unchecked for years become impossible to audit later.
• Pair IP blocking with fail2ban or cPHulk for login-specific brute force, since those catch credential-stuffing regardless of which IP it's coming from this week.
• Review the list every few months and remove stale entries — dynamic residential IPs get reassigned, and you can end up blocking an innocent visitor who inherited a blocked address.