Apache can be configured in two places: the main server and VirtualHost files that only root can edit, and per-directory .htaccess files that any site owner can drop into their folders. Both use mostly the same directives, but they behave very differently for speed and security. The switch between them is AllowOverride.
Before you start
- Root access to an Apache server, or a hosting account where you edit .htaccess.
- Know where your vhost files are:
/etc/apache2/sites-available/or/etc/httpd/conf.d/. See Apache virtual hosts setup.
How Apache processes .htaccess
When AllowOverride is not None, Apache must check for a .htaccess file in every directory on the path to the requested file, on every request. A request for /var/www/site/wp-content/uploads/2026/11/photo.jpg means looking for .htaccess in /, /var, /var/www, /var/www/site and each folder below. Each found file is parsed again every time; nothing is cached.
On a modern server with a warm filesystem cache the cost is small per request but adds up under heavy traffic, and rewrite rules in .htaccess are slower than the same rules in the vhost.
AllowOverride options
| Value | Allows in .htaccess |
|---|---|
None | Nothing; .htaccess is ignored and not even looked for |
All | Every directive permitted in .htaccess context |
FileInfo | Rewrite, redirects, headers, MIME types, error documents |
AuthConfig | Password protection (AuthType, Require) |
Indexes | Directory listing and index files |
Limit | Allow/deny style access control |
Options=... | Only the named Options, e.g. Options=FollowSymLinks |
AllowOverrideList can additionally permit individual directives by name, e.g. AllowOverrideList Redirect RedirectMatch, for very tight control.
A secure default
<Directory />
AllowOverride None
Require all denied
</Directory>
<Directory /var/www/example.com/public>
AllowOverride FileInfo AuthConfig
Options -Indexes +SymLinksIfOwnerMatch
Require all granted
</Directory>.htaccess is off everywhere by default and enabled only in the site's web root, with just the categories the app needs. FileInfo covers WordPress and most CMS rewrite rules.
Move rules into the VirtualHost
On a server you control, with one owner per site, putting rules in the vhost is faster and keeps config in one place.
- Copy the rules from
.htaccessinto a<Directory>block for the same folder in the vhost. Inside<Directory>, rewrite patterns behave like .htaccess (no leading slash), so rules usually work unchanged. - Set
AllowOverride Nonefor that directory. - Test:
sudo apachectl configtest && sudo systemctl reload apache2. - Rename the old file to
.htaccess.disabledso nobody is confused.
Remember: a plugin that writes to .htaccess (caching, security, SEO plugins) will no longer take effect. Copy its changes manually after updates.
When .htaccess is the right tool
- Shared and reseller hosting: users have no access to the vhost, so .htaccess is the only way to set redirects, protection and cache rules.
- Apps that manage their own rules: WordPress permalinks, LiteSpeed Cache, security plugins.
- Quick changes without reloading the server.
LiteSpeed Enterprise, used on MdmHost hosting, caches parsed .htaccess files and re-reads them only when they change, so the per-request cost largely disappears.
Troubleshooting
- .htaccess rules ignored:
AllowOverride Nonefor that directory, or mod_rewrite not enabled. - 500 "... not allowed here": the directive's category isn't permitted by AllowOverride. Allow it or move the directive to the vhost.
- Rules work in .htaccess but not in the vhost: you put them outside
<Directory>, where patterns include the leading slash. See mod_rewrite in depth.
FAQ: .htaccess vs VirtualHost
How much faster is disabling .htaccess?
It depends on directory depth and traffic. Measurable on busy servers, negligible on small sites.
Is .htaccess a security risk?
Only if too much is allowed. Restrict AllowOverride to what is needed.
Does Nginx support .htaccess?
No. Rules must go in the server block.