How to Block an IP Address Using .htaccess

An .htaccess file lets you block a single IP address, a range of addresses, or an entire network from reaching your site, without touching the main server configuration. This guide shows you the correct Apache 2.4 syntax to use on Noiz hosting, explains why the older order allow,deny snippets found on most of the internet now break, and covers the gotchas that catch people out, particularly when your site sits behind a CDN or reverse proxy.

Last reviewed: 27 July 2026, against Apache HTTP Server 2.4 (current stable series). This guide is written for Noiz hosting and is kept current against Apache. It complements, and does not replace, the official Apache documentation linked below.

Official Documentation Reference

• mod_authz_core: the Require directive
• mod_authz_host: Require ip and Require host
• Apache .htaccess tutorial
• Upgrading to 2.4: access control changes
• mod_remoteip: restoring the real client IP behind a proxy

Prerequisites

• A hosting plan running Apache or LiteSpeed. Both read .htaccess. Sites served by nginx alone ignore these files entirely.
• Access to your site files through the File Manager in your hosting control panel, or over SFTP.
• The IP address you intend to block, taken from your access logs rather than guessed.

Blocking a Single IP Address

Open (or create) the .htaccess file in the document root of the site you want to protect. On most plans that is httpdocs, public_html or web. Add the following near the top of the file:

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

Replace 203.0.113.45 with the address you want to block. That address is from a reserved documentation range and is only an example, so it will not block anything real.

Read it as two conditions that must both pass: the request is allowed in general, and it does not come from that IP. Anyone matching the blocked address receives a 403 Forbidden response.

Why the <RequireAll> wrapper matters. Several Require lines that are not wrapped in a container are treated as a RequireAny group, meaning any one of them passing is enough to grant access. A negated line such as Require not ip can never grant access on its own, so a group containing only negations always fails and a mixed unwrapped group quietly ignores your block. Wrapping the rules in <RequireAll> is what makes the exclusion actually apply.

Blocking Ranges, Networks and Multiple Addresses

Add one Require not line per entry inside the same container. Apache accepts several notations:

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
    Require not ip 198.51.100.0/24
    Require not ip 192.0.2
    Require not ip 2001:db8:abcd::/48
</RequireAll>

• 203.0.113.45 blocks one address.
• 198.51.100.0/24 blocks a CIDR network, in this case 256 addresses.
• 192.0.2 is a partial address, and blocks everything starting with those octets.
• IPv6 addresses and prefixes work in exactly the same way. If a visitor reaches your site over IPv6, blocking only their IPv4 address achieves nothing, so check your logs for both.

You can also block by hostname with Require not host example-crawler.net, but this forces a reverse DNS lookup on every request and is easy for an attacker to defeat. Prefer IP based rules.

Allowing Only Specific IP Addresses

For a staging site, an admin area or a client preview, an allow list is far stronger than a block list. This denies everyone except the addresses you name:

Require ip 203.0.113.45
Require ip 198.51.100.0/24

No container is needed here. Multiple positive Require lines behave as "any of these may pass", which is exactly what an allow list wants. Everyone else gets a 403.

Gotcha: most home and mobile connections use a dynamic IP that changes without warning. Lock yourself out this way and you will need File Manager or SFTP access to undo it, so confirm you have a second route in before you save.

Protecting a Single File or Directory

To restrict one file rather than the whole site, wrap the rules in a <Files> block. A common use is limiting access to a login script:

<Files "wp-login.php">
    Require ip 203.0.113.45
</Files>

To restrict a directory instead, place a separate .htaccess file inside that directory containing the rules. Directives in a subdirectory replace, rather than merge with, the authorisation rules inherited from the parent.

Why the Old order allow,deny Snippet No Longer Works

Older guides, including earlier versions of this article, recommended this:

order allow, deny
deny from IP-ADDRESS
allow from all

There are two problems with it.

1. The syntax is invalid. Apache expects Order allow,deny with no space after the comma. The space alone is enough to produce a 500 Internal Server Error on every page of the site, which is the usual reason a site goes down immediately after someone pastes in a blocking snippet.
2. The directives are obsolete. Order, Allow and Deny belong to the Apache 2.2 access control model, replaced in Apache 2.4 by the Require directives shown above. They only still function if the compatibility module mod_access_compat happens to be loaded, and mixing old and new style directives in the same context produces unpredictable results. Treat the old syntax as removed and convert any of it you find in existing files.

Blocking the Real Visitor IP Behind a CDN or Proxy

If your site runs through a CDN, a reverse proxy or a web application firewall, Apache sees the proxy's IP address on every request, not the visitor's. Two consequences follow:

• Blocking the address that appears in your logs may block the proxy itself, taking your whole site offline for every visitor.
• Blocking the visitor's true address does nothing, because Apache never compares against it.

The real address is normally carried in the X-Forwarded-For header, and the server needs mod_remoteip configured with the trusted proxy ranges before Require not ip will match it. That is a server level change, not an .htaccess one. Where a CDN is in front of your Noiz site, the cleanest fix is to apply the block in the CDN's own firewall rules, so unwanted traffic is stopped before it ever reaches the server. Open a ticket in the Noiz client area if you are unsure which applies to your setup.

Verifying the Block

1. Save the file and load your own site in a browser. If you see a 500 Internal Server Error, the file has a syntax error. Remove the lines you just added and re-add them carefully.
2. Check that the blocked address now receives a 403. If you cannot test from that address, a VPN or a mobile connection on a different network gives you a second vantage point.
3. Watch the access log for the blocked IP. Entries should continue to appear, now with status 403, which confirms the rule is matching rather than the visitor simply having stopped.

Changes take effect on the next request. No restart is needed, and no caching layer sits in front of .htaccess parsing.

Troubleshooting

Symptom: the entire site returns 500 Internal Server Error after editing. The rules contain a typo, a stray space (as in order allow, deny), or an unclosed container. Restore your backup of .htaccess, or comment the new lines out with # at the start of each.

Symptom: the blocked visitor still gets through. Check that the site actually reads this .htaccess file. A file in the wrong directory, or a subdirectory .htaccess with its own Require rules, will override what you expect. Confirm you are blocking the address the server sees, not the one a proxy is hiding.

Symptom: the rules are ignored entirely. AllowOverride may be set to None for that directory, which disables .htaccess processing. Raise a ticket in the Noiz client area to have it checked.

Symptom: you locked yourself out with an allow list. Edit the file through the File Manager in your control panel or over SFTP, neither of which is affected by web server access rules.

Symptom: blocking one address does nothing useful, because the traffic returns from a new one within minutes. That pattern points to a distributed source, and no .htaccess list will keep up with it.

Know the Limits: .htaccess Is Not a Firewall

These rules are applied by the web server, after the connection has been accepted, so a blocked request still consumes a connection slot and a small amount of CPU. That is fine for a nuisance scraper, a spam referrer or a single abusive address. It is not a defence against a flood, and a long block list maintained by hand becomes a maintenance burden that slows every request on the site, since Apache re-reads and re-evaluates .htaccess on each one.

For sustained or distributed abuse, blocking at the network edge is the right answer. Noiz servers run automated intrusion prevention that blocks repeat offenders at the firewall before the web server is involved, and CDN level rules stop traffic even earlier. If you find yourself adding addresses to .htaccess every day, open a ticket in the Noiz client area with a sample of the log lines and the Noiz team will advise on the right layer to block at, or apply it for you on managed plans.