Fix “X-LiteSpeed-Purge request failed (403 Forbidden)” in LiteSpeed Cache

What's happening:

The cache purge command is not getting through. LiteSpeed Cache is asking the server to clear cached pages, and the web server is replying with 403 Forbidden instead of accepting the purge.

Why this error shows up

LiteSpeed cache is controlled by special headers and rules. One of those is the X-LiteSpeed-Purge header. When the plugin sends it, LiteSpeed looks at the tags in that header and removes matching items from cache.

When you see X-LiteSpeed-Purge request failed (403 Forbidden), it means:

• The purge request reached the server,
• but something on the server side rejected it with 403 instead of processing it.

Most of the time, that comes down to one of these issues:

• LiteSpeed cache is disabled at server or vhost level for this site.
• A firewall or security rule is blocking purge requests or the X-LiteSpeed-Purge header.
• An .htaccess rule is returning 403 for the purge URL or query string.
• Your site is behind a proxy or different LiteSpeed instance and the purge request is hitting the wrong place.

Step 1: Confirm LiteSpeed cache is really available

Before chasing 403s, make sure the server actually allows LiteSpeed cache and purge.

Check response headers

1. Open your homepage in a private window.
2. Open your browser’s developer tools and go to the Network tab.
3. Reload the page and click the main HTML request.
4. Look for headers like X-LiteSpeed-Cache, X-LiteSpeed-Cache-Control or X-LSADC-Cache.

If you never see any LiteSpeed cache headers, the server may not be running LiteSpeed cache for this vhost.

Check the LiteSpeed report inside WordPress

1. In WordPress, go to LiteSpeed Cache → Toolbox → Report.
2. Look at the Server Variables section for LITESPEED_ON.

• If LITESPEED_ON is true, the site is running on LiteSpeed and cache can work.
• If it is NULL or empty, you are not on LiteSpeed Web Server. The plugin can still optimize HTML, but real server-level cache purge will not be available. In that case, this error usually points to a hosting mismatch, not a plugin bug.

If the report also shows a warning that “LSCache Module is disabled at the server level”, your host needs to enable the cache module before purge will succeed.

Step 2: See exactly what is being blocked

Next, you want to see the full log line around the error. That tells you which URL or header is triggering 403.

Enable the LiteSpeed debug log

1. Go to LiteSpeed Cache → Toolbox → Debug Settings.
2. Set Debug Log to ON or Admin IP Only.
3. Set Debug Level to Advanced and click Save Changes.
4. In another tab, click LiteSpeed Cache → Toolbox → Log View → Debug Log.
5. Back in WordPress, click Purge All (or repeat the action that shows the error).
6. Refresh the Debug Log and look for a line that mentions X-LiteSpeed-Purge and 403 or “request failed”.

Note the request path and query string. For example, it might be a call to /wp-admin/admin-ajax.php with a LSCWP_CTRL=PURGE_ALL parameter, or a front-end URL with cache control flags.

Step 3: Look for a security rule or firewall blocking purge

A very common cause is a security layer that thinks purge requests look suspicious and blocks them.

Temporarily disable security layers and test

1. Temporarily disable any security plugins (for example firewall, login protection, or hardening plugins).
2. If your host uses a server-side WAF or mod_security, check if they log rules for this site. If possible, temporarily disable or relax rules for your domain.
3. If you use a CDN WAF (Cloudflare, Sucuri, etc), set it to a relaxed mode or bypass for your IP.
4. Click Purge All again in LiteSpeed Cache and see if the 403 error disappears.

If purge works with security disabled but fails when you turn it back on, you have a rule to whitelist.

Whitelist the purge header or URL pattern

Once you know which rule is blocking things, you want to allow:

• The X-LiteSpeed-Purge response header, and
• The WordPress URLs used to trigger purge, often /wp-admin/admin-ajax.php or /wp-admin/admin.php?page=litespeed-toolbox with LSCWP_CTRL in the query string.

How you do this depends on the layer:

• Security plugin: add the purge URLs to its whitelist or “ignore rules.” Many security plugins let you exclude specific query strings or admin pages from filtering.
• WAF or mod_security: ask your host to whitelist the rule ID that is firing when X-LiteSpeed-Purge appears in the response or when LSCWP_CTRL is on the URL.
• CDN: create a firewall exception for requests coming from your own server IP or for the specific admin paths.

After whitelisting, purge again and confirm the 403 error no longer shows.

Step 4: Check .htaccess and file permissions

If no security layer is clearly blocking it, the 403 can come from local configuration.

Scan your .htaccess for “deny” or forced 403 rules

1. Open the .htaccess file in your site’s root.
2. Look for lines like Deny from all, Require all denied, or rewrite rules with the [F] flag (that flag forces 403).
3. Check if any of those rules match:
   • wp-admin/admin-ajax.php
   • wp-admin/admin.php with LiteSpeed query strings
   • or any URL that appears in your LiteSpeed debug log around the 403.

If you see a rule that applies to these URLs, try commenting it out or adjusting it so it does not apply to LiteSpeed cache actions. Many security stacks provide example “skip” rules that let you bypass protection for specific query strings.

Verify permissions on WordPress and cache directories

In your hosting file manager or over SFTP:

• Make sure folders are typically 755 and files are 644 (or whatever your host recommends).
• Check that the cache directory (often lscache under your document root) is readable and writable by the web server user.

If directories or files are too restrictive, LiteSpeed may not be able to read or write what it needs and can throw 403 instead of purging normally.

Step 5: If you are behind a proxy or separate LiteSpeed instance

On more advanced setups, your WordPress installation may sit behind another LiteSpeed or proxy server on a different IP. In that case, the plugin generates purge headers, but they might not reach the LiteSpeed instance that actually holds the cache.

Things to check with your host or sysadmin

• Confirm which server actually stores the LiteSpeed cache for your domain.
• Confirm that requests from WordPress to that server are allowed and not blocked by IP rules.
• If LiteSpeed is upstream from your WordPress vhost, you may need a custom purge route or curl-based purge script that runs on the caching server rather than relying only on plugin headers.

If hitting a simple PHP script that sends header('X-LiteSpeed-Purge: *'); works on the caching server, but pressing “Purge All” in WordPress fails with 403, that is a strong sign of a proxy or routing issue between WordPress and the LiteSpeed instance. Your host will need to align those.

Step 6: When to talk to your hosting provider

At this point you have:

• Confirmed LiteSpeed cache is enabled.
• Checked logs to see which URL or header is involved.
• Ruled out plugin-level security and obvious .htaccess rules.

If the 403 persists, it is likely controlled by server-level settings you cannot see. In your ticket to the host, include:

• The exact error text: X-LiteSpeed-Purge request failed (403 Forbidden).
• One or two recent lines from the LiteSpeed debug log that mention X-LiteSpeed-Purge and 403.
• Confirmation that you are trying to purge via the LiteSpeed Cache plugin inside WordPress.

Ask them to confirm that:

• The LiteSpeed cache module is enabled for your vhost.
• There are no server-level rules blocking X-LiteSpeed-Purge headers or the Purge URLs.
• If a proxy or load balancer is in front of your app, purge commands are reaching the correct LiteSpeed instance.

Verification checklist

You're in good shape once all of the following are true:

• Pressing Purge All in LiteSpeed Cache completes without showing “request failed (403 Forbidden)”.
• Your debug log no longer lists 403 responses for purge actions.
• Normal requests show X-LiteSpeed-Cache: hit for cached pages after the first load.
• Security plugins and WAF rules are still active, but have explicit exceptions for LiteSpeed purge.

Still stuck?

For AI help

Hit Continue Chat below and I’ll walk you through your logs, server environment, and security stack until we track down the exact rule that is causing the 403.

For expert human help

Scroll down to the contact form below. Enter your name, email, and WordPress needs. Atiba will get back to you as soon as possible.