Short answer: leave the LiteSpeed Cache plugin's built-in CDN tab off. Your site already runs behind Cloudflare, and turning on a second CDN layer inside the plugin doesn't add speed, it adds a second cache to keep in sync. The setting that actually matters is proxy mode on the Cloudflare CDN page in the portal, not anything inside WordPress.
This trips people up because the LiteSpeed Cache plugin ships with a CDN tab under its settings, and it looks like the natural place to wire up a CDN. On most hosts, sure. On Flashcloud, Cloudflare is already sitting in front of your site, so the plugin's CDN tab is solving a problem you don't have.
What's already running
Cloudflare backs DNS for shared and WordPress hosting, with proxy mode on by default for hosted domains. Whether Cloudflare also caches and serves your actual page content (static assets, sometimes full pages) depends on that proxy mode setting for your domain. See Setting up a CDN with Cloudflare for the full breakdown of what's automatic versus what you switch on.
Underneath that, your origin server is already fast on its own. We run LiteSpeed Web Server with LSCache, a full-page cache that serves cached pages from memory without touching PHP or the database. Every WordPress install gets the LiteSpeed Cache plugin pre-installed and pre-configured as the bridge to that server-level cache, plus a Redis object cache for database query results. Details in The cache stack we ship with every WordPress install and How we make your site fast.
Why the plugin's CDN tab is redundant here
The LiteSpeed Cache plugin's CDN settings exist to point your static asset URLs (images, CSS, JS) at a separate CDN hostname, something like cdn.yourdomain.com pointed at a third-party service. That pattern makes sense when your host doesn't already put a CDN in front of your traffic. On Flashcloud, Cloudflare is already the front door for every request to your domain when proxy mode is on. Rewriting your asset URLs to a second CDN endpoint means two caching layers with two different invalidation schedules, and a page that can look updated in one and stale in the other.
Leave the tab off. Your static assets are already served from Cloudflare's edge whenever proxy mode is on for your domain.
Where the real CDN switch lives
The control that matters is on the Cloudflare CDN page in the portal, under your hosting service. It's a per-domain toggle: proxy on routes traffic through Cloudflare's edge network (caching static assets, serving them from the location nearest each visitor); proxy off sends requests straight to origin and Cloudflare only handles DNS.
Proxy mode is on by default for domains on Flashcloud, and DDoS protection and edge caching only work while it stays on, so leave it on unless you have a specific reason to turn it off (for example, a service that must reach your origin IP directly). Either way, that switch lives on the portal page, not inside the WordPress plugin.
What to check if pages still look stale
- Purge LSCache from the plugin's cache-clearing option in wp-admin to clear the server-side full-page cache.
- Purge Cloudflare's cache from the
Cloudflare CDNpage in the portal if proxy mode is on for the domain. - Clear your own browser cache last. On most hosting accounts this is the most common false alarm and the easiest to rule out.
This is usually only needed after a theme change, a caching plugin conflict, or a manual edit outside WordPress (like a direct database change).
When to contact support
If you've purged both caches and a page still won't update, or you're seeing different content served to different visitors intermittently, open a ticket from Support in the portal. That's usually a sign of a misconfigured edge rule or a plugin conflict worth a second set of eyes.