This guide shows you how to block one or more IP addresses from reaching a website using a rule in the site's .htaccess file. It works on any website served by Apache, so you do not need a particular control panel to use it, and the rules travel with your site if you move it. If you would rather block an address from inside cPanel instead of editing a file by hand, see the companion guide How to Block an IP Address in cPanel.
Last reviewed: 27 July 2026, against the Apache HTTP Server 2.4 series (current stable). 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
- Apache HTTP Server: Access Control How-To
- Apache
mod_authz_core: theRequiredirective - Apache
mod_authz_host:Require ipandRequire host - Apache: Upgrading 2.2 access control to 2.4
Prerequisites
- Access to your website's files, through your hosting control panel's File Manager or over SFTP or FTP.
- The IP address you want to block. If you are acting on abusive traffic, take the address from your raw access logs or your control panel's visitor statistics so you block the right visitor.
- A site served by Apache. On Nginx and some other web servers the
.htaccessfile is ignored entirely, so these rules have no effect there.
Where the Rule Goes
The .htaccess file lives in your website's document root, usually the public_html or httpdocs folder, or inside the specific subfolder you want to protect. The rule applies to that folder and everything beneath it, so a file in the document root covers the whole site while a file in an admin subfolder restricts only that area.
The filename begins with a dot, which makes it hidden by default. Enable Show hidden files (dotfiles) in File Manager if you cannot see it, and create the file if it does not yet exist.
Back up first. A single typo in .htaccess can take the whole site offline with a 500 Internal Server Error, so download or copy the existing file before you change it. Restoring a known-good copy is the fastest way out of a bad edit.
Block a Single IP Address
Add the following block to your .htaccess file and save it. The Require all granted line keeps the site open to everyone, and Require not ip carves out the address you want to refuse.
<RequireAll>
Require all granted
Require not ip 203.0.113.45
</RequireAll>
Replace 203.0.113.45 with the address you want to block. The address shown is a reserved documentation example, so it is safe to paste while you find your way around, but it will not block anything real.
The block takes effect on the very next request. There is nothing to restart and no cache to clear. The blocked visitor receives a 403 Forbidden response.
Why the RequireAll Wrapper Is Not Optional
This is the detail most snippets on the web get wrong. Apache treats a plain list of Require lines as a RequireAny group, where any one satisfied condition grants access. A negated condition such as Require not ip can never grant access on its own, so left unwrapped it refuses everybody and takes your site down for all visitors.
Wrapping the pair in <RequireAll> changes the logic to "every condition must hold": access is granted, and the visitor is not the address you named. Always keep the two lines together inside the block.
Block Several Addresses, Ranges or Networks
Add as many Require not ip lines as you need, or list several values on one line separated by spaces. All the usual notations are accepted:
<RequireAll>
Require all granted
Require not ip 203.0.113.45 203.0.113.60
Require not ip 198.51.100.0/24
Require not ip 192.0.2
Require not ip 2001:db8::/32
</RequireAll>
- Single address:
203.0.113.45 - CIDR range:
198.51.100.0/24covers198.51.100.0through198.51.100.255 - Partial address:
192.0.2covers the whole192.0.2.*range, and192.0covers192.0.*.* - IPv6: full addresses and prefixes both work, for example
2001:db8::/32
Watch for the address family. If a visitor can reach your site over IPv6 and you have only blocked their IPv4 address, they will still get through. When you are dealing with a persistent nuisance, check your logs for both.
Allow Only Your Own Address
The reverse case is useful for a staging site or an admin folder that only you should reach. Place an .htaccess file containing this line inside the folder you want to restrict:
Require ip 203.0.113.45
Everyone except that address receives a 403 Forbidden. Replace the example with your own address, which you can find by searching the web for "what is my IP". No <RequireAll> wrapper is needed here because this is a positive condition rather than a negated one.
Take care with this on a home or mobile connection. Most residential and mobile lines use dynamic addresses that change without warning, so a rule that works today may lock you out tomorrow.
If You See the Older Apache 2.2 Syntax
Plenty of guides, and earlier versions of this article, use the older style:
Order allow,deny
Deny from 203.0.113.45
Allow from all
Two things are worth knowing about it. First, Order takes a comma-separated pair with no space after the comma. Writing order allow, deny is a syntax error that will bring the site down with a 500 Internal Server Error, and it is one of the most common causes of a site breaking immediately after an .htaccess edit.
Second, these directives were deprecated in Apache 2.4 and only function while the mod_access_compat module is loaded. That module is still present on many servers, but it is a compatibility shim rather than a supported long-term option, and mixing the old and new styles in the same configuration gives unpredictable results. Use the Require form shown above for anything new, and convert legacy rules when you next touch them rather than layering one style on top of the other.
Troubleshooting
Symptom: a 500 Internal Server Error appears as soon as you save. There is a syntax error in the file. Restore your backup, then re-add the rule carefully, checking for a stray space (as in order allow, deny), a missing </RequireAll> closing tag, or a directive your server does not support. Adding the lines back one at a time will identify the offending line quickly.
Symptom: every visitor is blocked, not just the address you named. The Require not ip line is missing its <RequireAll> wrapper and the accompanying Require all granted line. See the explanation above.
Symptom: the blocked visitor still gets through. The usual cause is that Apache is not seeing the visitor's real address. If your site sits behind a content delivery network, reverse proxy or firewall service, every request arrives from that service's own IP address and the visitor's address travels in a header instead. Block the visitor in the CDN or proxy control panel rather than in .htaccess. Otherwise, confirm you edited the .htaccess file in the document root actually serving the site, and that the address in your logs matches the one you blocked.
Symptom: the rule has no effect at all. Confirm the site runs on Apache and that AllowOverride permits these directives for the folder. On Nginx and other non-Apache servers, .htaccess is never read. If nothing in the file has any effect, open a support ticket and the team will confirm what your site is served by.
Symptom: you have blocked yourself. Reach your control panel from a different connection, such as mobile data or a phone hotspot, and edit the file to remove the rule. Control panel, FTP and SFTP access are separate from web access, so an .htaccess block never shuts you out of file management.
Good to Know
- What it covers: these rules control HTTP and HTTPS access to your website only. They do not block email, FTP or SSH.
- Dynamic addresses: a determined visitor on a home or mobile connection can pick up a new address within minutes. Blocking a range lasts longer, but weigh that against catching innocent visitors on the same network.
- Search engines: avoid blocking ranges belonging to search engine crawlers, or your pages may begin dropping out of search results.
- Scale:
.htaccessis read on every single request. A handful of block rules costs nothing measurable, but a list running to hundreds of entries is a sign the problem needs a firewall or CDN rule instead.
Need a Hand?
If you are on a managed Noiz plan and would like the block applied for you, or you are dealing with sustained abusive traffic that a single rule will not stop, open a support ticket from your Noiz client area and the team will help you put the right protection in place at the right layer.
