# Block IPs with .htaccess

Source: https://docs.fortrabbit.com/dev/htaccess/block-ip
Reviewed: 2026-06-10

> For broad protection against bad bots and common attacks, there is the built-in but experimental incoming firewall (WAF). When you only need to block a handful of known-bad IPs, a few .htaccess rules are enough.


For broad protection against bad bots and common attacks, there is the built-in but experimental [incoming firewall (WAF)](/platform/settings/firewall-incoming). When you only need to block a handful of known-bad IPs, a few `.htaccess` rules are enough.

## Block a single IP

fortrabbit runs Apache and supports both the 2.4 and the older 2.2 access syntax. The modern way uses `Require`:



```apache
<RequireAll>
    Require all granted
    Require not ip 203.0.113.42
</RequireAll>
```

Everyone keeps access except that one address, which gets a `403 Forbidden`. The same rule in the older 2.2 syntax:



```apache
Order Allow,Deny
Allow from all
Deny from 203.0.113.42
```

## Block an IP range

Pass a CIDR block to cover a whole range at once. This blocks all of `198.51.100.0/24`:



```apache
<RequireAll>
    Require all granted
    Require not ip 198.51.100.0/24
</RequireAll>
```

You can also shorten to the network prefix — `Require not ip 198.51.100` blocks the same `/24`. The 2.2 equivalent is `Deny from 198.51.100.0/24`.

## Block several addresses

Stack as many lines as you need inside one block:



```apache
<RequireAll>
    Require all granted
    Require not ip 203.0.113.42
    Require not ip 198.51.100.0/24
    Require not ip 192.0.2.0/24
</RequireAll>
```

## Allow only certain IPs

The inverse locks the door for everyone but a known address — handy for a maintenance window or a private staging area:



```apache
<RequireAll>
    Require ip 203.0.113.42
</RequireAll>
```

For password-based access to a staging area, [HTTP auth](/dev/htaccess/http-auth) is the friendlier option.

## Lighter and heavier alternatives

Blocking by IP is one point on a scale. Reach for a different tool depending on how much traffic you are up against.

### Ask bots to stay away with robots.txt

The lightest touch is a `robots.txt` in your web root. It asks crawlers not to visit:



```raw
User-agent: *
Disallow: /
```

This is a polite request, not a barrier. Well-behaved search engines honor it, while the scrapers and bad bots you most want to keep out routinely ignore it. Treat it as a hint, not protection.

### Block bot networks with the WAF

Hand-written IP rules work against a few known offenders. They do not scale to a bot network rotating thousands of addresses. For that, turn on the [incoming firewall (WAF)](/platform/settings/firewall-incoming). It is the same idea taken further — under the hood it is a maintained collection of `.htaccess` rules, the [nG Firewall](https://perishablepress.com/ng-firewall) by Perishable Press, that blocks bad requests and known bad bots on the web server level.

### Filter before it reaches the server

A CDN can drop bad traffic at the edge, before it ever reaches your App. [Cloudflare](/integrations/dns/cloudflare), for example, offers IP and firewall rules plus bot management on its network, which also spares your App the load.

---

- [Incoming firewall (WAF)](/platform/settings/firewall-incoming)
- [Redirects with .htaccess](/dev/htaccess/redirects)