To block an IP address from reaching your site, add Require not ip 123.45.67.89 inside a <RequireAll> block in your .htaccess file. To allow only specific IPs and block everyone else, use Require ip with the addresses you want to let through. Both directives work on Apache, which is what handles requests before PHP ever runs, so a blocked IP never touches your application code.
The exact syntax depends on which Apache version your directives target. Most current hosting stacks use the modern mod_authz_core syntax shown below, not the older Order, Allow, Deny syntax from Apache 2.2.
Blocking one or more IPs
To deny specific addresses while allowing everyone else, place this at the top of the .htaccess file in the directory you want protected:
<RequireAll>
Require all granted
Require not ip 123.45.67.89
Require not ip 98.76.54.0/24
</RequireAll>
Each Require not ip line adds one blocked address or range. The /24 notation blocks an entire subnet, in this case all 256 addresses from 98.76.54.0 to 98.76.54.255. Use a narrower or wider prefix depending on how much of the range you actually need to block.
Allowing only specific IPs
To restrict a directory so only certain addresses can reach it, invert the logic:
<RequireAll>
Require ip 123.45.67.89
Require ip 10.0.0.0/8
</RequireAll>
Anything not explicitly listed gets a 403 response. This pattern is common for staging environments, admin folders, or internal tools you don't want indexed or reached by the public.
Combining allow rules with authentication
You can pair an IP allow list with HTTP authentication so a request needs to satisfy both, or either. Replace <RequireAll> with <RequireAny> if you want IP-based access OR a valid login to count as authorized; keep <RequireAll> if both conditions must be true.
Where to put the file
The rules apply to the directory containing the .htaccess file and everything below it. If you want the restriction site-wide, edit the .htaccess in your domain's document root. If you only want it on one folder, like /admin, put a separate .htaccess file inside that folder instead. You can edit these files directly with the File Manager tile in the portal, or through an FTP client using credentials from FTP Accounts.
Common mistakes
- Locking yourself out. If you're allowing specific IPs and your own address changes (common on home internet or mobile connections), you'll get a 403 on your own site. Check your current public IP before saving, and add a wider range if your ISP rotates addresses frequently.
- Mixing old and new syntax.
Order, Allow, DenyandRequiredirectives don't combine cleanly. Pick one syntax and use it consistently in a given block. - Forgetting subnets. Blocking a single IP does nothing if the visitor is on a dynamic address or behind a proxy that rotates addresses. A single-IP block is a short-term fix, not a lasting one.
- Applying it to the wrong directory. Rules cascade downward, not upward. A rule in a subfolder's
.htaccessdoesn't protect the parent directory.
When IP blocking isn't the right tool
Manual IP blocks in .htaccess work well for a known, stable set of addresses: a specific bad actor, an internal office IP range, a partner's server. They don't scale well against distributed abuse, botnets, or attackers who rotate addresses, since you'd be editing the file constantly. For ongoing malicious traffic, active scanning, or brute-force attempts, Imunify360's web application firewall handles that automatically at the account level and adapts as attack patterns change, which is a better fit than a hand-maintained block list.
If you've locked yourself out of your own site and can't edit the file over FTP either, or you're not sure whether a rule you added is causing a 403 for legitimate visitors, open a ticket from the portal's Support section and our team can help.