How to Fix LiteSpeed Cache Admin Login or Redirect Loop

A LiteSpeed Cache admin login or redirect loop usually means WordPress is not getting a clean login session. The cause may be browser cookies, LiteSpeed page cache, object cache, CDN cache, HTTPS redirects, or rules in .htaccess. Start with the cache and cookie layers you can clear safely, then disable LiteSpeed Cache only if you still cannot reach wp-admin.

Quick checks before changing files

Open the login page in a private browser window first. If private mode works, clear cookies for the site in your normal browser, then try /wp-login.php and /wp-admin/ again.

If you use Cloudflare, QUIC.cloud, another CDN, or host-level caching, purge that cache before changing WordPress files. Public support threads around LiteSpeed Cache lockouts often involve cache that has to be cleared outside wp-admin, including cases where the site owner specifically needed to purge LiteSpeed cache without wp-admin or WP-CLI.

Check where the loop happens:

• Only wp-admin loops: suspect cookies, object cache, security plugins, login protection, or cached admin redirects.
• Both the front end and wp-admin loop: suspect HTTPS, domain redirects, .htaccess, CDN rules, or host-level redirects.
• The loop started after enabling Redis or object cache: disable object cache first.
• The loop started after a LiteSpeed Cache setting change: disable LiteSpeed Cache before editing unrelated WordPress settings.

Safest fix order

1. Purge CDN, host, and LiteSpeed cache

If you can still access wp-admin, go to LiteSpeed Cache > Toolbox > Purge and purge cache there. LiteSpeed documents the purge tools in its LiteSpeed Cache Toolbox guide, including Purge All – LSCache, Purge All, and Empty Entire Cache.

If you cannot access wp-admin, purge cache from the layer you can reach:

• Hosting control panel cache tool
• LiteSpeed WebAdmin or hosting cache panel, if your host exposes it
• QUIC.cloud dashboard
• Cloudflare or another CDN dashboard

Do this before deactivating plugins. If the loop is being served by a CDN or server cache, WordPress changes may not appear to work until that outer cache is cleared.

2. Disable LiteSpeed Cache without wp-admin

If the login loop continues and you cannot reach wp-admin, use your host’s file manager or SFTP.

Go to:

wp-content/plugins/

Rename:

litespeed-cache

to something like:

litespeed-cache.disabled

WordPress will stop loading the plugin because the plugin folder is no longer where it expects it. WordPress documents the same recovery principle in its guidance on deactivating plugins when the administrative menus are unavailable.

Now clear CDN or host cache again, then try logging in.

If login works, leave LiteSpeed Cache disabled while you check the settings below. Do not immediately reactivate it and save the same configuration.

3. Turn off object cache before re-enabling page cache

A redirect loop that starts after enabling Redis or another object cache should be treated differently from a normal page-cache issue. Object cache can preserve login/session-related state in a way that survives a normal page cache purge.

After you regain wp-admin access:

1. Rename the plugin folder back to litespeed-cache.
2. Log in.
3. Go to LiteSpeed Cache > Cache > Object.
4. Turn Object Cache off.
5. Save.
6. Purge all cache.
7. Test wp-admin again before enabling object cache.

LiteSpeed’s object cache settings documentation notes that the plugin supports external object caches such as Redis or Memcached and includes a separate Cache WP Admin setting, which can return stale admin data if object cache is misbehaving.

If your Redis host uses a Unix socket path, enter the full socket path supplied by your host. Avoid shorthand paths such as ~ unless your host explicitly documents that the plugin accepts them. A public LiteSpeed Cache support case involved a Redis socket path using ~ followed by loss of admin access.

4. Check logged-in cookie and admin caching settings

LiteSpeed has specific settings for logged-in users, login cookies, and HTTP/HTTPS compatibility. In its cache settings documentation, Cache Logged-in Users stores logged-in pages in private cache by IP and session ID. The same documentation also describes Login Cookie and warns that mixed HTTP/HTTPS access can create login-cookie conflicts.

For a locked-out admin issue, keep the recovery posture simple:

• Do not cache wp-admin.
• Do not cache login pages.
• Turn off Cache Logged-in Users while testing.
• Disable guest optimization temporarily.
• Disable object cache temporarily.
• Purge all cache after each change.

Then test login in a private browser window. If it works, re-enable features one at a time instead of restoring every cache setting at once.

5. Check redirect rules outside LiteSpeed Cache

If disabling LiteSpeed Cache does not stop the loop, the cause is probably not the plugin alone.

Check these places next:

• Hosting panel redirects
• Cloudflare Page Rules, Redirect Rules, or Bulk Redirects
• WordPress Settings > General site URL and home URL, if wp-admin is reachable
• .htaccess rules on Apache or LiteSpeed servers
• Security plugins that rename or protect the login page
• Theme or custom plugin code redirecting logged-in users

For Apache/LiteSpeed sites, WordPress explains the standard permalink rewrite block in its Apache and .htaccess documentation. If .htaccess contains old HTTPS, domain, or login redirects above the WordPress block, back up the file before removing or changing anything.

Optional SSH method

Use WP-CLI only if your host provides SSH and you are comfortable with command-line recovery. It is not required for most site owners.

To deactivate LiteSpeed Cache:

wp plugin deactivate litespeed-cache

To list active plugins if the loop continues:

wp plugin list --status=active

If WP-CLI cannot connect to the database, fix the database connection first. Plugin commands will not help until WordPress can load.

How to confirm it worked

A real fix should pass all of these checks:

• /wp-login.php accepts the login and reaches the dashboard.
• /wp-admin/ does not bounce back to the login form after authentication.
• The issue stays fixed in a normal browser window after clearing site cookies.
• The issue stays fixed after purging CDN and host cache.
• Re-enabling LiteSpeed Cache does not bring the loop back with object cache disabled.

If the loop returns only after one LiteSpeed feature is turned back on, leave that feature off and collect a report number from LiteSpeed Cache > Toolbox > Report before contacting LiteSpeed support. LiteSpeed’s Toolbox Report documentation explains that the report includes settings, installed plugins, and .htaccess contents, and that public support requests can reference the generated report number.

Rollback and escalation

If renaming the plugin folder did not help, rename it back so the site returns to its previous plugin state, then escalate based on where the loop remains:

• Contact the host if redirects continue with LiteSpeed Cache disabled and CDN cache purged.
• Contact the CDN provider if the loop appears only through the CDN hostname.
• Contact LiteSpeed support if the issue returns only when LiteSpeed Cache or object cache is enabled.
• Contact the Redis/object-cache provider if the loop began after changing Redis host, socket, port, or authentication settings.

Keep one cache layer disabled while testing. Re-enabling LiteSpeed Cache, CDN cache, host cache, and object cache all at once makes it much harder to identify which layer is sending WordPress back into the loop.