Yes. WP Ghost is fully compatible with LiteSpeed Cache and the QUIC.cloud CDN, and most of the integration is automatic. Since version 8.0.20, WP Ghost fetches QUIC.cloud’s published edge IPs and adds them to its firewall whitelist on every settings save, so the CDN is never mistaken for an attacker. It writes its firewall and path rules in the format LiteSpeed reads natively, keeps your hidden login, REST, and temporary-login URLs out of the cache, and applies path hiding inside LiteSpeed’s own cache buffer so even fully cached pages stay protected.
The only thing to check on advanced stacks is that the real visitor IP is passed through the CDN correctly. For the hands-on configuration, follow the WP Ghost and LiteSpeed Cache setup guide; this article explains how each part of the integration works.
Short Answer
LiteSpeed and QUIC.cloud are two different things that people often lump together. LiteSpeed Cache is the WordPress plugin plus the LiteSpeed web server’s built-in page cache, both running on your server. QUIC.cloud is a separate CDN run by LiteSpeed that sits in front of your site as a reverse proxy, handling edge caching, image and CSS optimization, and an edge WAF.
WP Ghost is built to handle both. Path security, the 7G and 8G firewall, brute force protection, and the hidden login, REST, and temp-login URLs all work behind LiteSpeed and QUIC.cloud, and the parts that would normally cause friction are handled for you.
What QUIC.cloud Is, and Why It Matters for Security
The detail that matters for any security plugin is this: with QUIC.cloud enabled, a large share of your traffic arrives from QUIC.cloud’s edge IPs, not from the real visitor’s IP. A reverse-proxy CDN forwards every request through a handful of edge servers.
For a security plugin that rate-limits and blocks by IP, that creates two risks if it is not handled. First, the firewall could see thousands of requests from a few QUIC.cloud IPs and rate-limit or block the CDN itself. Second, brute force protection and Geo Security could act on the CDN’s IP instead of the actual attacker’s. WP Ghost is designed around both of these, which is what the rest of this guide covers.
How WP Ghost Works with LiteSpeed and QUIC.cloud
Firewall and path rules use the LiteSpeed-native format
LiteSpeed reads .htaccess the same way Apache does. WP Ghost detects a LiteSpeed server and writes its path-hiding and firewall rewrite rules in Apache and .htaccess format, so hidden paths and the 7G and 8G firewall run natively at the web server layer with no extra configuration. This is the same prevention-first model WP Ghost uses everywhere: bad requests are rejected before WordPress loads. See Firewall Security for the firewall details.
QUIC.cloud edge IPs are whitelisted automatically
This is the most important part for most users, and it happens on its own. After every settings save, WP Ghost retrieves QUIC.cloud’s full published IP list, validates each entry, and adds those IPs to the firewall whitelist. The CDN edge is therefore never treated as an attacker, while real-visitor protection keeps working behind it. This behavior was added in WP Ghost 8.0.20, so on current versions you do not have to whitelist QUIC.cloud IPs by hand.
Hidden login, REST, and temp-login URLs stay out of the cache
A cache and a secret URL can conflict. You do not want your renamed login page or hidden REST endpoint served from a stale cache, and you do not want temporary-login tokens cached and reused. So when you change paths, WP Ghost adds the right exclusions to LiteSpeed Cache: your custom login URL and your hidden REST path are added to LiteSpeed’s Do Not Cache list, and the temporary-login token is excluded from query-string caching. Your secret paths keep working correctly even on cached pages.
Path hiding applies inside cached pages
Normally WP Ghost rewrites paths through its own output buffer. LiteSpeed has its own buffer too, and two buffers competing can cause blank pages or double processing. To avoid that, WP Ghost steps aside while LiteSpeed is optimizing and instead performs its find-and-replace inside the LiteSpeed cache buffer. The result is that fully cached pages still have wp-content, wp-includes, and admin paths hidden, with no leaks. The toggle that enables this is Change Paths in Cache Files, documented in Change Paths in Cached Files.
Cache is refreshed when you change settings
When you apply new paths, create sites on a multisite network, or change settings, WP Ghost triggers a LiteSpeed cache flush so old cached HTML carrying the previous paths does not linger. If you ever see stale paths, purging the LiteSpeed cache and the QUIC.cloud CDN cache once resolves it.
Compatibility at a Glance
| Feature | Works with LiteSpeed + QUIC.cloud? | Notes |
|---|---|---|
| Path hiding (wp-content, admin, includes) | Yes | Applied inside the LiteSpeed buffer, so it works on cached pages |
| 7G / 8G firewall and rewrite rules | Yes | Written as .htaccess rules; OpenLiteSpeed needs vhost config |
| Brute force and IP firewall behind the CDN | Yes | QUIC.cloud edge IPs are auto-whitelisted so the CDN is not blocked |
| Hidden login, REST, and temp-login URLs | Yes | Auto-excluded from LiteSpeed Cache |
| Image, CSS, and JS optimization (QUIC.cloud) | Yes | Optimization scan requests are detected and not buffered |
The One Thing to Check: Real Visitor IP Behind the CDN
Because traffic flows through QUIC.cloud, the real visitor IP has to be passed through correctly for brute force blocking, Geo Security, and threat logs to target the actual attacker rather than the CDN. QUIC.cloud forwards it, typically in the X-Forwarded-For header, and WP Ghost reads the forwarded IP automatically. In most setups there is nothing to configure.
On a misconfigured stack, for example an extra proxy in front of QUIC.cloud, or a host that strips the forwarded header, you may see one of two symptoms: the CDN’s IP appears in WP Ghost’s logs instead of the visitor’s, or legitimate visitors get blocked because they all appear to come from one IP. The fix is to confirm your proxy chain forwards X-Forwarded-For to the origin. If the symptom persists after that, send the details to WP Ghost support. This is a configuration issue in the proxy chain, not a plugin bug.
A Note for OpenLiteSpeed Users
The points above assume LiteSpeed Enterprise or a LiteSpeed server that honors .htaccess. OpenLiteSpeed, the open-source edition, does not load .htaccess by default, so the firewall and path rewrite rules must be enabled through the vhost configuration first. Follow Config .htaccess in OpenLiteSpeed once, and the rest of the integration behaves the same as on Apache and LiteSpeed Enterprise.
Frequently Asked Questions
Do I have to whitelist QUIC.cloud IPs manually?
No, not on current versions. Since WP Ghost 8.0.20, the plugin fetches QUIC.cloud’s published edge IPs and adds them to the firewall whitelist automatically on every settings save. Manual whitelisting stays available as a fallback if the automatic list is ever stale, for example right after QUIC.cloud publishes new edge IPs. You can add them under WP Ghost > Firewall > Whitelist > Whitelist IPs from the list at quic.cloud/ips. The setup guide covers this step.
Does WP Ghost slow down LiteSpeed or QUIC.cloud?
No. The firewall and path rules run as .htaccess rules at the web server layer, so malicious requests are rejected before PHP and WordPress start. For sites under bot pressure, that reduces load rather than adding it. Path hiding on cached pages happens inside the LiteSpeed buffer, so there is no second buffer competing for the same output.
Will my hidden login URL break when it is cached?
No. WP Ghost adds your custom login URL and your hidden REST path to LiteSpeed’s Do Not Cache list, and excludes temporary-login tokens from query-string caching. Your secret paths are served live, not from a stale cached copy, so they keep working correctly behind the cache and the CDN.
Do I still need WP Ghost if QUIC.cloud has its own WAF?
Yes. The QUIC.cloud edge WAF filters known attack patterns at the network edge, but it does not hide your WordPress fingerprints. Bots scanning for /wp-login.php, /wp-admin, or /wp-content/plugins/ still receive valid responses, because the edge does not know those URLs should be hidden. WP Ghost removes the target from view, so attacks never identify your site as WordPress in the first place. The edge WAF filters known attacks; WP Ghost takes the site off the map. The two layers complement each other.
Does this work with WooCommerce?
Yes. WP Ghost is fully compatible with WooCommerce, and LiteSpeed Cache supports WooCommerce as well. Make sure LiteSpeed excludes cart, checkout, and account pages from caching, which it normally does by default, so dynamic pages stay current.
Does WP Ghost modify WordPress core files?
No. WP Ghost uses server-level rewrite rules and WordPress filters. No core files are modified. Deactivating WP Ghost restores every original path and default instantly, with no leftover performance cost.
Related Tutorials
WP Ghost with cache and CDN platforms:
- WP Ghost and LiteSpeed Cache Setup Guide – Step-by-step configuration for LiteSpeed Cache and QUIC.cloud.
- Change Paths in Cached Files – The toggle that keeps custom paths intact on cached pages.
- Config .htaccess in OpenLiteSpeed – Required first step on OpenLiteSpeed.
- WP Ghost and WP Rocket – Cache and CDN compatibility with WP Rocket.
- Firewall Security – How the 7G and 8G firewall protect at the server layer.
- Compatible Plugins List – All plugins tested with WP Ghost.