AIOS OpenLiteSpeed compatibility and .htaccess configuration

AIOS OpenLiteSpeed Compatibility: Does .htaccess Work?

by

AIOS OpenLiteSpeed compatibility can be confusing because the security plugin uses both PHP-based protection and Apache-style .htaccess rules.

The direct answer is that All-In-One Security, also known as AIOS, can run on WordPress websites using OpenLiteSpeed, but not every .htaccess security feature will work exactly as it does on Apache.

OpenLiteSpeed can load Apache mod_rewrite rules from an .htaccess file when the feature is enabled. However, it does not support every Apache directive. Unsupported directives are ignored, which means some AIOS protections may work while others require an OpenLiteSpeed-specific configuration.

This guide explains what works, what may not work, and how to configure AIOS safely on an OpenLiteSpeed WordPress server.

Is AIOS Compatible With OpenLiteSpeed?

AIOS is partially compatible with OpenLiteSpeed, but the answer depends on the particular AIOS feature.

Many AIOS protections operate through PHP and WordPress itself. These generally work independently of whether the server uses Apache, Nginx, LiteSpeed Enterprise, or OpenLiteSpeed.

Other AIOS features add rules to the website’s .htaccess file. These need additional attention because OpenLiteSpeed does not provide complete Apache .htaccess compatibility.

The current AIOS plugin includes both PHP firewall rules and .htaccess firewall rules. Its features include login lockouts, two-factor authentication, file scanning, REST API controls, XML-RPC protection, bot blocking, 6G firewall rules and sensitive-file protection.

The practical conclusion is:

AIOS can protect an OpenLiteSpeed WordPress website, but you should rely primarily on its PHP-based features and configure any required server-level protections directly in OpenLiteSpeed.

Why .htaccess Works Differently on OpenLiteSpeed

Apache reads many types of configuration directives from .htaccess, including:

  • Rewrite rules
  • Access-control directives
  • Directory options
  • File restrictions
  • Upload limits
  • Server signature settings
  • Authentication directives

OpenLiteSpeed handles .htaccess differently.

Current OpenLiteSpeed versions can automatically load .htaccess files, but only supported rewrite rules are processed. Unsupported Apache directives are ignored.

For example, an Apache access rule such as this may not work on OpenLiteSpeed:

Order Deny,Allow
Deny from all

OpenLiteSpeed’s official documentation states that .htaccess is supported for rewrite rules, not general Apache access-control directives. File and directory restrictions should instead be implemented with rewrite rules or OpenLiteSpeed contexts.

Therefore, the presence of AIOS rules inside .htaccess does not automatically prove that OpenLiteSpeed is enforcing them.

AIOS Features That Should Work on OpenLiteSpeed

The following AIOS features are mainly handled through WordPress or PHP and should generally work on OpenLiteSpeed:

  • Login attempt lockouts
  • Two-factor authentication
  • Login CAPTCHA
  • User account monitoring
  • Logged-in user session management
  • File change scanning
  • File-permission checks
  • Database-prefix tools
  • Comment spam controls
  • 404 monitoring
  • Audit logging
  • REST API restrictions
  • PHP-based XML-RPC protection
  • PHP-based firewall rules
  • IP block and allow lists
  • 5G and 6G firewall protection when handled through PHP
  • Fake Googlebot detection
  • Blank user-agent and referrer checks

AIOS moved its 6G firewall feature into the PHP Rules section in version 5.4.3, which improves its usefulness on non-Apache server environments.

You should still enable advanced security options one at a time and test the website after every change.

AIOS Features That Require Additional Checking

Features that specifically modify .htaccess may not work completely on OpenLiteSpeed.

These can include:

  • Denying access through Apache Order, Allow or Deny directives
  • Disabling the server signature
  • Setting file-upload limits through Apache directives
  • Disabling directory indexes through Apache Options
  • Protecting individual files with unsupported <Files> blocks
  • HTTP authentication implemented with Apache-only directives
  • Custom rules that are not written as RewriteRule and RewriteCond
  • Rules that depend on unsupported Apache modules

Some protections can be recreated with OpenLiteSpeed rewrite rules. Others should be configured through the OpenLiteSpeed WebAdmin Console.

Step 1: Back Up the Website and Server Configuration

Before changing AIOS or OpenLiteSpeed:

  1. Create a full WordPress backup.
  2. Download a copy of the existing .htaccess file.
  3. Back up the OpenLiteSpeed virtual-host configuration.
  4. Record the AIOS options currently enabled.
  5. Perform the changes on staging when possible.

Security rules can generate unexpected 403 errors or block access to the WordPress dashboard. A backup gives you a safe rollback option.

Step 2: Update AIOS and OpenLiteSpeed

Use the latest stable versions of:

  • WordPress
  • AIOS
  • OpenLiteSpeed
  • PHP
  • LiteSpeed Cache, when installed

Current AIOS versions contain substantially more PHP-based firewall functionality than older releases. Using an old tutorial or outdated AIOS version may produce different results from those described here.

OpenLiteSpeed also recommends updating to the latest release before reporting unexpected server behaviour because the problem may already have been corrected.

Step 3: Enable .htaccess Loading in OpenLiteSpeed

Log in to the OpenLiteSpeed WebAdmin Console.

The default WebAdmin address is commonly:

https://your-server-ip:7080

Navigate to:

Virtual Hosts > Your Virtual Host > Rewrite

Set:

Enable Rewrite: Yes
Auto Load from .htaccess: Yes

Save the changes and perform a graceful restart.

You can also configure it directly in the virtual-host configuration:

rewrite  {
  enable                  1
  autoLoadHtaccess        1
}

OpenLiteSpeed must reload its configuration after rewrite settings are changed.

From SSH, the server can be restarted with:

sudo systemctl restart lsws

You can alternatively use the Graceful Restart button in WebAdmin.

Important limitation

Enabling Auto Load from .htaccess does not make OpenLiteSpeed fully compatible with Apache.

It enables supported rewrite rules. General Apache directives can still be ignored.

Step 4: Prioritize AIOS PHP Firewall Rules

In WordPress, go to:

AIOS > Firewall > PHP Rules

Review and enable the required protections one at a time.

Depending on the current AIOS version, this area may include:

  • Basic firewall protection
  • Block access to XML-RPC
  • Disable pingback functionality
  • Deny bad query strings
  • Advanced character-string filtering
  • 5G or 6G firewall protection
  • REST API restrictions
  • Internet-bot protection
  • Blank user-agent and referrer blocking

PHP firewall rules are more portable because they do not depend on Apache interpreting .htaccess.

Do not enable every advanced rule simultaneously on a live site. Some rules can block legitimate REST API requests, webhook calls, form submissions, advertising parameters or external services.

After enabling each option:

  1. Clear the LiteSpeed cache.
  2. Open the website in an incognito window.
  3. Test the WordPress login.
  4. Test forms and checkout pages.
  5. Test the REST API.
  6. Check scheduled tasks and external integrations.
  7. Review the AIOS audit log.

Step 5: Add OpenLiteSpeed-Compatible File Protection

OpenLiteSpeed supports access restrictions through rewrite rules.

The following example blocks requests to several files that should not normally be publicly accessible:

# BEGIN DebugNexus OpenLiteSpeed Security

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{REQUEST_URI} (?:^|/)(?:\.htaccess|error_log|debug\.log|wp-config-sample\.php|readme\.html|readme\.txt|license\.txt|install\.php|wp-config\.php|php\.ini|php5\.ini|bb-config\.php)$ [NC]
RewriteRule .* - [F,L]

</IfModule>

# END DebugNexus OpenLiteSpeed Security

Place this block before the standard WordPress rewrite section:

# BEGIN WordPress

This example is adapted from OpenLiteSpeed’s documented method for blocking multiple sensitive files with RewriteCond and RewriteRule.

Do not add the rule twice

Choose one of these locations:

  • The website’s root .htaccess file, when Auto Load is enabled
  • The OpenLiteSpeed virtual-host Rewrite Rules field

Do not place identical rules in both locations.

Rule syntax in the WebAdmin Rewrite tab

When adding a direct file rule in the virtual-host Rewrite tab, allow for an optional leading slash:

RewriteRule ^/?xmlrpc\.php$ - [F,L]

When the rule is inside an automatically loaded root .htaccess file, use:

RewriteRule ^xmlrpc\.php$ - [F,L]

OpenLiteSpeed evaluates virtual-host and directory-level rewrite patterns differently, so the leading slash may need to be adjusted.

Step 6: Block XML-RPC When It Is Not Needed

WordPress uses xmlrpc.php for certain remote-publishing and communication features.

When your website does not need XML-RPC, you can block it through AIOS’s PHP firewall.

That is generally preferable because it does not depend on .htaccess.

You can also block it at the OpenLiteSpeed level.

For an automatically loaded root .htaccess file:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^xmlrpc\.php$ - [F,L]
</IfModule>

For the OpenLiteSpeed virtual-host Rewrite Rules field:

RewriteRule ^/?xmlrpc\.php$ - [F,L]

Do not add this rule when a required application uses XML-RPC. Examples can include the WordPress mobile app, Jetpack features or external publishing software.

Step 7: Disable Directory Listing in OpenLiteSpeed

Do not depend on an Apache Options -Indexes rule because OpenLiteSpeed may not process it.

OpenLiteSpeed disables auto-indexing by default, but you should confirm the setting.

In WebAdmin, go to:

Virtual Hosts > Your Virtual Host > General > Index Files

Set:

Auto Index: No

You can also configure this at the server or context level. A context-level setting overrides the virtual-host setting, while a virtual-host setting overrides the server-level setting.

Step 8: Configure Security Headers Natively

Some .htaccess security-header rules may not be processed as expected.

OpenLiteSpeed allows headers to be configured through a static context.

Navigate to:

Virtual Hosts > Your Virtual Host > Context

Create or edit the context for / and use the Header Operations field.

Common headers include:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=()

HSTS and Content Security Policy should not be copied blindly. An incorrect configuration can break subdomains, third-party scripts, fonts, payment gateways or embedded resources.

OpenLiteSpeed documents native header configuration through the virtual-host context and recommends restarting the server after saving the changes.

Step 9: Test Whether the Rules Work

Do not assume a feature works because AIOS shows it as enabled.

Test the actual response.

Test a protected file

Run:

curl -I https://example.com/readme.html

A correctly blocked file should normally return:

HTTP/2 403

or:

HTTP/1.1 403 Forbidden

Test XML-RPC

Run:

curl -I https://example.com/xmlrpc.php

When XML-RPC is blocked, expect a 403 response or the configured AIOS denial response.

Test WordPress permalinks

Open several:

  • Posts
  • Pages
  • Categories
  • Search-result pages
  • Pagination URLs
  • WooCommerce endpoints, when applicable

A rewrite mistake can create widespread 404 errors.

Test the REST API

Open:

https://example.com/wp-json/

When the AIOS REST API restriction is enabled, test both logged-in and logged-out requests. Plugins, mobile applications, webhooks and external services may require REST API access.

Fixing 403 Errors After Enabling AIOS

When the site starts returning unexpected 403 errors, do not immediately deactivate every security feature.

Go to:

AIOS > Firewall > PHP Rules

Temporarily disable recently enabled rules one at a time.

Common rules worth testing include:

  • Deny bad query strings
  • Advanced character-string filter
  • 5G firewall
  • 6G firewall
  • Unauthorized REST API blocking
  • Blank user-agent and referrer blocking

AIOS support has identified these features as common areas to check when legitimate requests are blocked.

After changing a rule:

  1. Clear the LiteSpeed cache.
  2. Clear any CDN cache.
  3. Retest in an incognito window.
  4. Review the AIOS audit log.
  5. Check the OpenLiteSpeed error log.

What to Do When .htaccess Changes Are Ignored

When OpenLiteSpeed ignores a rewrite rule, check the following:

Auto Load is not enabled

Confirm:

Enable Rewrite: Yes
Auto Load from .htaccess: Yes

OpenLiteSpeed was not restarted

Perform a graceful restart after changing rewrite settings or rules.

The rule uses an unsupported directive

Rewrite the protection using:

RewriteCond
RewriteRule

Or configure it through an OpenLiteSpeed context.

The rule has the wrong leading slash

Inside a root .htaccess file:

RewriteRule ^xmlrpc\.php$ - [F,L]

Inside the virtual-host Rewrite Rules field:

RewriteRule ^/?xmlrpc\.php$ - [F,L]

A cache is hiding the result

Purge:

  • LiteSpeed Cache
  • Object cache
  • Cloudflare
  • QUIC.cloud
  • Browser cache

The wrong .htaccess file was edited

Confirm that you edited the .htaccess file in the active WordPress document root.

Do Not Edit the AIOS Plugin Files

Some old troubleshooting discussions suggest changing files directly inside:

/wp-content/plugins/all-in-one-wp-security-and-firewall/

Do not use this as a permanent fix.

Plugin updates will overwrite the changes. Direct edits can also introduce syntax errors, weaken security or make future troubleshooting difficult.

Use one of these methods instead:

  • AIOS settings
  • An MU plugin
  • OpenLiteSpeed rewrite rules
  • OpenLiteSpeed contexts
  • A documented WordPress filter
  • A server-level firewall

Recommended AIOS Configuration for OpenLiteSpeed

A practical OpenLiteSpeed setup is:

  • Use AIOS login lockout.
  • Enable two-factor authentication for administrators.
  • Enable CAPTCHA where required.
  • Use the AIOS PHP firewall.
  • Use PHP-based XML-RPC and REST API controls.
  • Use PHP-based 6G protection.
  • Use AIOS audit logging and file scanning.
  • Configure sensitive-file blocking in OpenLiteSpeed.
  • Disable auto indexing in OpenLiteSpeed.
  • Configure security headers in OpenLiteSpeed.
  • Use LiteSpeed Cache only for caching and optimization.
  • Enable options gradually and test each one.

AIOS should complement server-level security rather than replace it.

Frequently Asked Questions

Does OpenLiteSpeed read .htaccess?

Current OpenLiteSpeed versions can automatically load .htaccess files when the setting is enabled. However, only supported rewrite functionality is processed. Unsupported Apache directives are ignored.

Will all AIOS firewall rules work on OpenLiteSpeed?

No. PHP-based rules should generally work, but Apache-specific .htaccess directives may not.

Does AIOS conflict with LiteSpeed Cache?

The plugins perform different primary jobs and can generally operate together. However, AIOS firewall rules can block REST API calls, crawlers, webhooks or other requests used by cache and CDN services. Test these features after enabling stricter firewall options.

Should I use AIOS .htaccess rules?

You can use supported mod_rewrite rules after enabling .htaccess loading. Do not rely on unsupported Apache directives.

Is LiteSpeed Enterprise different from OpenLiteSpeed?

Yes. LiteSpeed Enterprise offers broader Apache compatibility. OpenLiteSpeed is not a complete drop-in Apache replacement, so behaviour documented for LiteSpeed Enterprise may not always apply to OpenLiteSpeed.

Final Answer

AIOS OpenLiteSpeed compatibility is good for WordPress-level and PHP-based security features, but it is not complete for every .htaccess feature.

OpenLiteSpeed can load supported rewrite rules from .htaccess, but it ignores unsupported Apache directives. The safest configuration is to use AIOS for PHP firewall protection, login security, two-factor authentication, auditing and scanning, while using OpenLiteSpeed’s native settings for file restrictions, directory listing and security headers.

Always enable security options gradually, test the actual HTTP responses and keep a rollback method available.

Leave a Comment