Apache "client denied by server configuration" (AH01630) Fix

This Apache error means an access control rule matched your request and said no. The visitor gets a 403 Forbidden page, and the error log records the filesystem path that was denied. In Apache 2.4 the log line carries the code AH01630. Apache 2.2 logged the same words without a code.

The classic trigger is upgrading from Apache 2.2 to 2.4 or copying a vhost from an old tutorial. The access control system was rewritten, and 2.2-style directives silently stop working or reverse their meaning.

[authz_core:error] [pid 1523] [client 203.0.113.8:51234] AH01630: client denied by server configuration: /var/www/example.com/public/

Causes, most likely first

1. Old Order allow,deny and Allow from all syntax in a 2.4 server without the compatibility module, so the rules do nothing and the default Require all denied wins.
2. A missing Require all granted in the <Directory> block for your document root.
3. The document root lies outside the directories Apache is allowed to serve. On Debian and Ubuntu, /etc/apache2/apache2.conf allows only /var/www/ and /usr/share. A site in /home/user/site or /srv/site needs its own block.
4. A restrictive .htaccess or an IP allowlist (Require ip) that does not include you.
5. Another module's rule, such as a security module or <Files> block, matching the path.

Fix 1: use Apache 2.4 syntax

Look at the denied path from the log, then find the matching Directory block.

# Old (2.2) - does not work as expected on 2.4
<Directory /var/www/example.com/public>
    Order allow,deny
    Allow from all
</Directory>

# New (2.4)
<Directory /var/www/example.com/public>
    Options -Indexes +FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

Mapping of the common old patterns:

Test and reload:

sudo apachectl configtest
sudo systemctl reload apache2      # httpd on RHEL-based systems

Fix 2: allow a document root outside /var/www

In apache2.conf the global rule is a deny for everything outside the listed paths. If your site is elsewhere, declare it explicitly. Putting the block in the vhost file is cleanest:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /srv/example/public
    <Directory /srv/example/public>
        Require all granted
    </Directory>
</VirtualHost>

Fix 3: the compatibility module (temporary only)

If you cannot rewrite old configuration right away, 2.4 includes mod_access_compat, which understands the old directives:

sudo a2enmod access_compat      # Debian and Ubuntu
sudo systemctl restart apache2

Mixing old and new styles within one context is unreliable, so use this only as a stopgap while you migrate.

Fix 4: check .htaccess

grep -rn -E "Order|Allow from|Deny from|Require" /var/www/example.com/public/.htaccess

Remove stale blocks. Note that .htaccess is only read where AllowOverride permits it; if AllowOverride None is set, its contents are ignored.

Not the same: filesystem permission denials

If the log instead reads AH00035: access to / denied (filesystem path '/home/user/site') because search permissions are missing on a component of the path, the problem is Unix permissions, not configuration. The Apache user (www-data or apache) needs execute permission on every parent directory:

namei -l /home/user/site/public/index.html
sudo chmod o+x /home/user /home/user/site

Files should usually be 644 and directories 755. On SELinux systems also check ls -Z and use chcon -R -t httpd_sys_content_t /srv/example, or semanage fcontext and restorecon to make it permanent. If no index.html or index.php exists and Options -Indexes is set, you also get a 403, but with the message AH01276.

How to verify

Request the URL and confirm the status changes from 403 to 200:

curl -I http://example.com/

The HTTP Status Checker shows the same from outside your network, and the HTTP Header Checker confirms the Server: Apache header and any redirect. If you used IP rules, test from an allowed and a blocked address. Watch sudo tail -f /var/log/apache2/error.log while you retry; no new AH01630 line should appear. The HTTP 403 reference covers the status code in general, and an Uptime Monitor on the homepage alerts you if a config change brings it back.

Next steps

• Check the response with the HTTP Status Checker.
• Read Apache vs nginx troubleshooting for log locations and commands on both.
• Review Fix 500 Internal Server Error if the page now returns a 500.
• Check that crawlers are not blocked unintentionally with the robots.txt Checker.

FAQ

What replaced Order, Allow and Deny in Apache 2.4?

The Require directives from mod_authz_core, such as Require all granted, Require ip and Require not ip.

Why did my site break after an OS upgrade?

The upgrade likely moved you from Apache 2.2 to 2.4 and your old vhost used the 2.2 syntax. Rewrite the access rules with Require, or temporarily enable mod_access_compat.

Can a wrong file owner cause this error?

Not this exact message. Ownership and permissions cause AH00035 or similar filesystem denials, while AH01630 comes from configuration rules.

Does .htaccess affect this?

Yes, if AllowOverride allows it. A Require all denied or an IP allowlist in .htaccess returns the same error.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.