LiteSpeed Cache breaks REST API auth (WP Vibe) and Matomo internal request routing — reproducible, confirmed via clean preset baseline
Environment:
- WordPress 7.1, PHP 8.4.24
- Host: Mechanic Web (cPanel/LiteSpeed, uses LiteSpeed Web Cache Manager at server level —
- Relevant plugins: LiteSpeed Cache, Matomo Analytics for WordPress (bundled Matomo core, not standalone), Redis Object Cache (via LiteSpeed's built-in Object Cache module), MalCare Security, Wordfence
Issue 1 — REST API authentication fails while LiteSpeed Cache is active
A third-party app connecting via the WordPress REST API (using an Application Password) reliably gets an HTTP 401 on the REST root (
Issue 2 — Matomo's internal archiving requests get mishandled
On the Matomo Diagnostics → Troubleshooting page, clicking "Archive reports" submits a normal
-
- An
Because the browser correctly honors the (incorrect) JSON content type, it displays the full raw HTML output as plain text instead of rendering it, and the archiving action does not complete.
Confirmed via a live traffic test: visited the site via VPN, and the new visit did not appear in Matomo reports while LiteSpeed Cache was active; disabling LiteSpeed Cache and clicking Archive reports immediately picked up the missed traffic.
Troubleshooting already performed (no effect on either issue)
- Cache REST API toggle (on/off)
- ESI (was already off)
- CDN/QUIC.cloud (not in use)
- Object Cache (Redis) — toggled off entirely, no change
- Commented out
- Excluded the Matomo troubleshooting URL under Cache → Excludes → Do Not Cache URIs
- Full LSCache Debug Log (Admin IPs Only, verbose) — showed no log entry at all for the failing request, suggesting the plugin's own cache logic isn't what's intercepting it
- Reset entirely to the "Advanced (Recommended)" configuration preset as a clean baseline — both issues persist unchanged
Notes
Since the issue survives a full preset reset and isn't tied to any single dashboard toggle, it seems to point to something at a lower level than the plugin's settings — possibly related to the
Environment:
- WordPress 7.1, PHP 8.4.24
- Host: Mechanic Web (cPanel/LiteSpeed, uses LiteSpeed Web Cache Manager at server level —
.litespeed_flag present in document root)- Relevant plugins: LiteSpeed Cache, Matomo Analytics for WordPress (bundled Matomo core, not standalone), Redis Object Cache (via LiteSpeed's built-in Object Cache module), MalCare Security, Wordfence
Issue 1 — REST API authentication fails while LiteSpeed Cache is active
A third-party app connecting via the WordPress REST API (using an Application Password) reliably gets an HTTP 401 on the REST root (
/wp-json/) whenever LiteSpeed Cache is active. Deactivating the LiteSpeed Cache plugin entirely resolves it immediately — reconnection succeeds every time with no other changes. Reactivating the plugin reproduces the 401 again. This was tested repeatedly and consistently correlates with the plugin's on/off state alone.Issue 2 — Matomo's internal archiving requests get mishandled
On the Matomo Diagnostics → Troubleshooting page, clicking "Archive reports" submits a normal
<form method="post"> back to admin.php?page=matomo-systemreport&tab=troubleshooting. While LiteSpeed Cache is active, the response comes back with:-
Content-Type: application/json (should be text/html)- An
x-matomo-request-id response header — not a standard WordPress or LiteSpeed header, indicating Matomo's own internal request router is intercepting this navigation instead of it being handled normally by admin.phpBecause the browser correctly honors the (incorrect) JSON content type, it displays the full raw HTML output as plain text instead of rendering it, and the archiving action does not complete.
Confirmed via a live traffic test: visited the site via VPN, and the new visit did not appear in Matomo reports while LiteSpeed Cache was active; disabling LiteSpeed Cache and clicking Archive reports immediately picked up the missed traffic.
Troubleshooting already performed (no effect on either issue)
- Cache REST API toggle (on/off)
- ESI (was already off)
- CDN/QUIC.cloud (not in use)
- Object Cache (Redis) — toggled off entirely, no change
- Commented out
CacheLookup on in .htaccess directly- Excluded the Matomo troubleshooting URL under Cache → Excludes → Do Not Cache URIs
- Full LSCache Debug Log (Admin IPs Only, verbose) — showed no log entry at all for the failing request, suggesting the plugin's own cache logic isn't what's intercepting it
- Reset entirely to the "Advanced (Recommended)" configuration preset as a clean baseline — both issues persist unchanged
Notes
Since the issue survives a full preset reset and isn't tied to any single dashboard toggle, it seems to point to something at a lower level than the plugin's settings — possibly related to the
<IfModule LiteSpeed> directives written into .htaccess, or an interaction specific to this host's server-level LiteSpeed Web Cache Manager setup. Happy to provide the exact .htaccess LSCACHE block, full request/response headers, or grant temporary access if that would help investigate.