iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The correct rule depends on your Apache version. Apache 2.2 uses Order with Deny from; Apache 2.4 uses the authorization syntax Require. To block every client on Apache 2.2, use Order Allow,Deny followed by Deny from all. On Apache 2.4, use Require all denied. A rule in .htaccess applies only to the directory and URL paths governed by that file, and the server must allow the relevant overrides.
Identify the Apache version before writing a rule
Deny from is part of Apache HTTP Server 2.2’s access-control syntax. Apache 2.4 replaced that authorization model with Require. The two forms should not be treated as interchangeable: a directive that works on one version can be ignored, rejected, or require a compatibility module on the other.
| Apache version | Preferred syntax | Block everyone | Typical selected-client form |
|---|---|---|---|
| 2.2 | Order, Allow from, and Deny from |
Order Allow,DenyDeny from all |
Order Allow,DenyAllow from allDeny from ... |
| 2.4 | Require authorization directives |
Require all denied |
<RequireAll> with Require all granted and one or more negated Require not ip lines |
If you do not know the version, check the hosting control panel, ask the server administrator, or inspect the server’s documented version information before changing the file. A migration from 2.2 to 2.4 is not just a capitalization change; it changes the authorization syntax and the modules involved.
Check these prerequisites before editing
A .htaccess file is read in per-directory context. Apache will only process the directives if the administrator has enabled the appropriate override class with AllowOverride. On a server that disallows overrides, Apache may ignore the file or return an error rather than apply the rule.
#1 Best Overall
- Confirm the directory: Put the file in the directory whose resources you want to protect. The rule also affects URL paths below that directory according to Apache’s per-directory processing.
- Confirm the server version: Use the 2.2 or 2.4 form that matches the running server.
- Keep a recovery path: Before denying everyone, retain administrative access through a separate location, server console, file manager, or deployment system.
- Preserve a copy: Save the working file so you can restore it immediately if the new directive causes an error.
- Know the impact: Access-control rules normally apply to all HTTP methods handled in that directory, not only to
GETrequests. - Check the error log: Your host’s Apache error log is the authoritative place to identify an unknown directive, syntax error, or module problem after an edit.
The Apache 2.4 documentation describes the authorization phase this way:
“The
Requiredirective is used during the authorization phase to ensure that a user is allowed or denied access to a resource.” — Apache Software Foundation, Apache HTTP Server 2.4 mod_authz_hostWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchSpecial offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Block every visitor in a directory
Apache 2.4: use Require all denied
For a current Apache 2.4 server, place this rule in the .htaccess file for the directory that must be closed:
Require all deniedThis is Apache’s complete-denial rule. Every client reaching a resource in that directory’s scope is refused, regardless of the client’s IP address. It is the clearest replacement for the old “deny from all” objective on Apache 2.4.
Do not add an old Order line merely because it appeared in a previous 2.2 configuration. Use the 2.4 authorization model unless you have a specific compatibility reason to retain legacy directives.
Rank #2
- Used Book in Good Condition
Apache 2.2: combine Order and Deny from
On Apache 2.2, the documented complete-denial pattern is:
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Order Allow,Deny
Deny from allOrder Allow,Deny tells Apache how the allow and deny sets are evaluated. With Deny from all, every client is denied in the directory governed by the file. The Order line matters; copying only the Deny from all line into a configuration with a different evaluation order can produce a different result.
Apache 2.2 describes this family of directives as a way to restrict access based on hostname, IP address, or environment variables. If an older site still depends on this syntax while running on Apache 2.4, the mod_access_compat module can provide older directives, but compatibility is a transition measure rather than the preferred design for a new rule.
Apply and verify the block safely
- Back up the existing
.htaccessfile. - Add the version-appropriate rule without changing unrelated rewrite or authentication directives.
- Save the file with plain text encoding and the exact filename
.htaccess. - Request a page inside the protected directory from an authorized test connection. A complete denial should produce an HTTP authorization failure rather than the page content.
- Check the Apache error log and your host’s configuration-test procedure if the server returns an HTTP 500 error or the result is unexpected.
- If you lock yourself out, restore the backup or remove the denial through your separate administrative access path.
Deny selected IP addresses on Apache 2.4
Apache 2.4 supports IP-based authorization with Require ip. To allow everyone except selected addresses or ranges, combine a positive requirement with negated requirements:
<RequireAll>
Require all granted
Require not ip 203.0.113.42
Require not ip 2001:db8:1234::/48
</RequireAll>The first line grants a general baseline. Each Require not ip line subtracts a prohibited address or network. In this example, the single IPv4 address 203.0.113.42 and the IPv6 network 2001:db8:1234::/48 are denied, while other clients remain eligible.
Why a positive requirement is mandatory
A negated requirement is an exclusion, not a complete authorization decision. Require not ip 203.0.113.42 by itself cannot authorize a request. Apache requires it to be combined with a positive requirement, normally inside <RequireAll>, as shown above. Omitting Require all granted can lead to a configuration error or an authorization result that does not express the intended policy.
Address formats accepted by Require ip
The 2.4 directive accepts full addresses, partial IPv4 prefixes, CIDR or netmask ranges, and IPv6 forms. Use the narrowest form that represents the clients you actually want to block.
| Match | Example | What it represents |
|---|---|---|
| One IPv4 address | Require not ip 203.0.113.42 |
One IPv4 client address |
| IPv6 network | Require not ip 2001:db8:1234::/48 |
The specified IPv6 CIDR network |
| Additional IPv4 or IPv6 range | Add another Require not ip line |
Each line adds another exclusion to the same policy |
Use the address that Apache sees at the connection layer. If a proxy or load balancer sits in front of Apache, the apparent client address may be the proxy unless the server is separately configured to restore and trust forwarded client addresses. Do not deny an entire proxy network unless you have verified which address Apache evaluates.
Deny selected IP addresses on Apache 2.2
The legacy pattern grants access first and then lists the addresses to deny:
Order Allow,Deny
Allow from all
Deny from 203.0.113.42 198.51.100.This example denies the individual IPv4 address 203.0.113.42 and the partial IPv4 prefix 198.51.100., while allowing other clients. The trailing dot in the second value illustrates the legacy partial-prefix form. Because Order controls how the allow and deny sets are evaluated, verify the complete policy rather than inserting these lines into an unknown existing order.
For an older server, keep the entire access policy in one understandable block. Mixing a legacy allow/deny block with unrelated authorization directives makes it harder to determine which rule wins and complicates a later upgrade to Apache 2.4.
Choose the right match: address, subnet, IPv6, or hostname
Single address
Use a full IPv4 or IPv6 address when one known client must be blocked. This is the least broad IP match and reduces the chance of denying unrelated users who happen to share a provider or network.
IPv4 subnet or partial prefix
Use CIDR, a netmask, or the documented partial-prefix style to cover a network. A subnet can represent many clients, so check the range before deployment. On Apache 2.4, express the range with Require not ip; on Apache 2.2, use the corresponding value after Deny from.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
IPv6 range
IPv6 clients should be matched with an IPv6 address or CIDR range, such as 2001:db8:1234::/48. Do not assume that blocking an IPv4 address also blocks the same user over IPv6; those are separate address families.
Hostname-based matching
Apache’s access-control documentation includes hostname-based restrictions, but hostname rules depend on name resolution and the server’s resolver behavior. They can change when DNS changes and may add lookup overhead. For a stable exclusion policy, an explicit IP or network is easier to audit. If you must use a hostname match in an older configuration, verify its exact syntax and resolution behavior against the Apache version and the existing Order policy before relying on it.
Best Value
- Used Book in Good Condition
Understand the scope of a .htaccess rule
A rule in /site/private/.htaccess, for example, governs that directory and the URL paths below it, not every directory on the server. A file in a document root can therefore affect a much larger portion of a site than a file in a nested directory. Place the rule as close as practical to the resources it protects.
The same restriction generally covers all HTTP methods handled in that directory. Blocking a client therefore affects requests such as form submissions, API calls, and other methods as well as ordinary page loads. If you intended to protect only one endpoint or one operation, a directory-wide access rule may be broader than necessary.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsFor a server-wide policy, the administrator should normally configure authorization in the main virtual-host or server configuration instead of distributing it through many .htaccess files. That approach requires administrative access and is outside a site’s per-directory override. A hosting account that permits .htaccess may still prohibit the relevant authorization override class; only the server administrator can change that restriction.
Migrating a legacy rule to Apache 2.4
When a site moves from Apache 2.2 to 2.4, translate the policy rather than carrying forward old lines unchanged.
- Record the intended result: deny everyone, or allow everyone except named addresses and networks.
- Replace a complete 2.2 block of
Order Allow,DenyandDeny from allwithRequire all denied. - Replace a 2.2 allow-all-plus-deny list with a
<RequireAll>block containingRequire all grantedand oneRequire not ipline for each excluded address or range. - Check for
mod_access_compat. It exists to support older directives, but relying on it can conceal an incomplete migration. - Test the resulting file on the actual Apache 2.4 server and inspect the error log for unsupported or conflicting directives.
Do not assume that a 2.2 block and a 2.4 block can safely coexist simply because both mention an allow or deny decision. Use one coherent authorization model for each directory.
Quick Recap
Troubleshoot common failures
| Symptom | Likely cause | What to check |
|---|---|---|
| HTTP 500 immediately after saving | Unknown directive, malformed syntax, unsupported module, or an invalid nesting block | Restore the backup, read the Apache error log, confirm the server version, and run the host’s configuration test before reapplying the change |
| The rule has no visible effect | The file is outside the requested path, overrides are disabled, or a different configuration controls the request | Verify the file’s directory scope and ask the administrator whether the relevant AllowOverride class is enabled |
Deny from is rejected on Apache 2.4 |
The server is using the 2.4 authorization model without legacy compatibility support | Convert the rule to Require, or have the administrator confirm whether mod_access_compat is intentionally enabled |
| A supposedly blocked user still connects | Apache is seeing a proxy or load-balancer address, the client is using IPv6, or the address range is too narrow | Inspect the address recorded by Apache, check both address families, and verify the CIDR or prefix |
| Everyone is locked out | A complete-denial rule was placed at too high a directory level or without an administrative exception | Use the recovery path, remove or narrow the rule, and test from a controlled connection before enabling it again |
Practical deployment checklist
- Identify Apache 2.2 versus 2.4.
- Decide whether the policy is complete denial or an exclusion list.
- Choose the smallest directory scope that meets the requirement.
- Use
Require all deniedfor complete denial on 2.4. - Use
Order Allow,DenyplusDeny from allfor complete denial on 2.2. - For 2.4 exclusions, combine
Require all grantedwith negatedRequire not ipdirectives inside<RequireAll>. - For 2.2 exclusions, grant all and list the addresses after
Deny from. - Include IPv6 ranges explicitly when they are part of the block requirement.
- Confirm that
AllowOverridepermits the directives. - Back up the file and retain an administrative recovery path.
- Test the result and inspect the Apache error log before considering the change complete.
Quick decision guide
| Your objective | Apache 2.2 | Apache 2.4 |
|---|---|---|
| Close one directory to everyone | Order Allow,DenyDeny from all |
Require all denied |
| Allow everyone except one IPv4 address | Order Allow,DenyAllow from allDeny from 203.0.113.42 |
<RequireAll>Require all grantedRequire not ip 203.0.113.42</RequireAll> |
| Block an IPv6 network | Use the legacy deny syntax verified for the running 2.2 configuration | Add Require not ip with the IPv6 CIDR range inside <RequireAll> |
| Protect the whole virtual host or server | Ask the administrator to configure the main server or virtual-host context | Ask the administrator to configure the main server or virtual-host context |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
