Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Traffic control · Intermediate · 10 min

How to block unwanted visitors by IP — Blocking by IP: Count First, Then Pick the Layer

One address hammering your login endpoint is an IP Blocker job; four hundred addresses doing the same thing is not, and the log tells you which one you have.

View WooCommerce Hosting plansBrowse more How-To Library

The short answer

Count first: cut -d' ' -f1 access.log | sort | uniq -c | sort -rn | head tells you in one command whether you are facing one persistent address or a distributed pattern, and those two problems have completely different answers.

Then block at the cheapest layer that can see the traffic. Network-edge DDoS filtering is cheaper than server-level Imunify, which is cheaper than cPanel's IP Blocker writing into .htaccess, which is cheaper than a plugin that has already booted PHP to make its decision. The further out the rejection happens, the less of your allowance it consumed.

By the HostingFast team · Reviewed 24 August 2026

Intermediate

Assumed level

5

Stages to done

Free

Support cost

Proven

Verified on production

Ten minutes: one command to identify the offenders, one screen to block them, one check to confirm it worked, and a note in the diary to review the list later.

The commands assume SSH, which is on every shared tier. If you would rather not use a terminal, AWStats will show you the same top-visitors data with fewer options for slicing it.

Count before you block anything

The distribution is the diagnosis. One address with 40,000 requests is a pest, and blocking it solves the problem outright. Four thousand addresses with ten requests each is a distributed pattern, and an IP list will never catch up with it — you will spend an evening adding entries while the source pool rotates underneath you.

Get the shape in one line: cut -d' ' -f1 access.log | sort | uniq -c | sort -rn | head -20. Then confirm what the top offenders are actually asking for with grep on the address, because scraping, form spam and credential stuffing each deserve a different response.

Choose the layer by what the request costs you

A request rejected at the network edge costs you nothing. One rejected by Imunify at server level costs a little. One rejected by an .htaccess deny — which is what cPanel's IP Blocker writes — costs a config parse and a 403 response. One rejected by a security plugin has already loaded PHP, connected to MySQL and booted your application, which is the most expensive way possible to say no.

So the rule is: push the rejection outwards. DDoS filtering at the edge and Imunify at server level handle volume and patterns. The IP Blocker is the right instrument for a small number of specific, persistent addresses — and it is genuinely good at that.

CIDR without collateral damage

Abusers move within their provider's allocation, so blocking a single address often just moves the problem next door. A /24 fences off 256 addresses and is usually a proportionate response; a /16 fences off 65,536 and almost certainly catches somebody you wanted. Look up who owns the range before you widen, because the allocation may be a hosting provider (fine) or a mobile carrier (not fine).

Shared NAT is the specific trap. Office networks, university campuses and mobile carriers put thousands of genuine users behind a handful of public addresses. A wide block there does not stop an attacker; it silently removes a segment of your customers, and nobody will email to tell you.

The list is a liability that only grows

Address allocations are recycled. Last year's abuser is this year's genuine reader, and a blocklist that only ever accumulates entries is quietly accruing false positives you cannot see. Date every entry when you add it, note why, and review quarterly.

There is also a limit worth knowing: a very long deny list in .htaccess is parsed on every request to that document root. A few dozen entries is nothing; several hundred is a cost you are paying on every legitimate page view too, and at that point the answer is server-level filtering rather than a longer file.

The network filtering that soaks up attacks before they reach a site

The layers already sitting in front of your account

DDoS filtering is absorbed out at the network edge and Imunify runs at server level on every account here, so the IP Blocker is the last and narrowest of several layers rather than your only defence.

LiteSpeed in front of NVMe storage means legitimate cached traffic is answered without touching PHP, which is why abusive uncached requests stand out so clearly in the log.

  • One command that tells you which problem you have
  • Layers ranked by what a rejected request costs
  • CIDR guidance with the NAT trap called out
  • Engineers on the desk at any hour, including mid-incident

Why HostingFast

Standard on every plan

Diagnosis before action

The request distribution decides whether an IP list is the right tool at all, and one command gives you that distribution.

Layers ranked by cost

Edge, server, .htaccess, plugin — with the price of each rejection stated, so you push the block outwards.

Ranges done carefully

/24 versus /16 with real numbers, plus a WHOIS check before you widen anything.

The NAT trap, named

Why a wide block silently removes real customers behind office and mobile networks, and how to avoid it.

Maintenance built in

Dated entries, a quarterly review, and the point at which a long deny list becomes its own performance cost.

Escalation path included

Where the blocker stops and Imunify plus edge filtering take over, so you stop asking one tool to do both jobs.

Quick Start

From order to online

  1. 1

    Extract the offenders in one command

    cut -d' ' -f1 access.log | sort | uniq -c | sort -rn | head -20. If the top entry dwarfs the rest, blocking will work. If the counts are flat across hundreds of addresses, stop here — this is a job for server-level filtering.

  2. 2

    Confirm what they are actually requesting

    grep the address and read a hundred lines. Repeated POSTs to a login path, sequential requests through your catalogue, or hits on a single form each imply a different fix. Blocking without reading is how you block a search crawler.

  3. 3

    Add the address, or a justified range, in IP Blocker

    cPanel's IP Blocker accepts single addresses and CIDR ranges and writes them into .htaccess. Check the range ownership with a WHOIS lookup before widening beyond a /24.

  4. 4

    Verify the block from outside your own network

    Watch the log for that address returning 403 instead of 200, or test from a different connection. A block you have not confirmed is an assumption sitting in a config file.

  5. 5

    Date the entry and diarise the review

    Note when and why. Every quarter, remove anything you can no longer justify — allocations get reassigned, and a list that only grows will eventually turn away somebody you wanted.

Built In

Loaded onto every plan

  • DDoS filtering absorbed out at the network edge
  • Imunify protection running at server level on every account
  • cPanel IP Blocker for individual addresses and CIDR ranges
  • Raw access logs plus AWStats in the Metrics section
  • Full SSH access with Git and Composer on every shared plan
  • LiteSpeed caching in the server, so legitimate traffic rarely reaches PHP
  • NVMe SSD storage on every tier, not only the expensive ones
  • Human support on duty every hour of every day
  • Money-back cover: 30 days on hosting plans, 7 on reseller
  • Renewal billed at the rate you signed up at, with no setup fee

Frequently Asked

What people ask us most often

How many requests from one address justify a block?

There is no universal threshold, which is why the distribution matters more than the count. Compare the top offender against your median visitor: an address making 40,000 requests when a real reader makes fifteen is unambiguous. An address making 200 when your busiest genuine users make 150 is probably a feed reader or a monitoring service. Read what it requested before deciding — behaviour discriminates better than volume.

Will blocking a range catch real customers behind shared NAT?

It can, and this is the main reason to be conservative. Corporate networks, university campuses and especially mobile carriers put large numbers of genuine users behind a small pool of public addresses. Block a /16 belonging to a mobile network and you have removed a slice of your mobile traffic without any error appearing anywhere you would look. Check ownership first, prefer /24 or narrower, and treat consumer ISP ranges with real caution.

Does an IP block actually save server resources?

Some, depending on where it happens. A deny in .htaccess still costs a connection, a config parse and a 403 response — but it avoids PHP, the database and your application entirely, which is the expensive part. Blocking at server level with Imunify or out at the network edge saves more still. What saves nothing is a plugin-level block, because by the time it runs, the request has already paid for everything except the response body.

What does Imunify handle that the IP Blocker does not?

Pattern and volume. Imunify runs at server level with a view across the whole machine, so it can recognise distributed brute force, known attack signatures and behaviour that no single address makes obvious. The IP Blocker has no pattern recognition at all — it denies exactly what you list. Use it for specific, persistent, identified offenders, and leave campaigns to the layers designed for them.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Filtering that starts before your PHP does.

DDoS filtering at the network edge, Imunify at server level, cPanel's IP Blocker for the stubborn individuals, and engineers reachable at any hour.

View WooCommerce Hosting plans