Connect QUIC.cloud CDN to LSCache on a cPanel server

QUIC.cloud is the CDN built by the LiteSpeed team specifically to cache LSCache-tagged responses at the edge. Unlike Cloudflare or BunnyCDN, it understands LiteSpeed's per-page tag invalidation, so a single WordPress post update purges the right URLs at every PoP instead of every page going stale on TTL. For shared-hosting customers it's also the cheapest path to a global CDN with image optimization included — the free tier covers most low-traffic sites, and paid credits scale linearly without per-site contracts.

This guide assumes you already have LSCache running on a cPanel server. If not, start with enabling LSCache for WordPress fleet-wide — QUIC.cloud is a thin layer on top of an already-working origin cache, not a replacement for it.

Prerequisites

• LiteSpeed Web Server Enterprise on cPanel with the WordPress LSCache plugin active
• An active LSWS license — QUIC.cloud also works with OpenLiteSpeed, but the per-site account-linking flow below assumes the WHM/cPanel integration
• Outbound HTTPS to quic.cloud from the server (the IP allowlist is published at https://quic.cloud/ips)
• DNS control for each domain that will sit behind the CDN

The site owner needs to complete one step per domain — the CDN cannot be enabled fleet-wide from WHM, only the LSCache plugin can.

Step 1 — Create a QUIC.cloud account and claim the domain

Visit https://quic.cloud and sign up. The account is free; usage credits are charged separately and the free monthly allowance covers ~10 GB CDN traffic and 500 image optimization requests per domain.

From the WordPress admin of any site on the server, go to LiteSpeed Cache → General → General Settings and click Link to QUIC.cloud. The plugin opens an authorization window — log in to your QUIC.cloud account and approve the domain link. On return, the plugin populates the Domain Key field automatically.

If the popup is blocked or the redirect fails (common behind corporate proxies), use the Request Domain Key button instead. QUIC.cloud emails the key to the account address; paste it into the field manually and save.

Step 2 — Enable the CDN service for the domain

Back in LiteSpeed Cache → CDN → QUIC.cloud Settings, flip Cloud Services to ON. This unlocks four sub-services that activate independently:

• CDN — edge caching across the QUIC.cloud PoP network
• Image Optimization — server-side WebP/AVIF conversion and recompression
• Page Optimization — CSS/JS minify and combine at the edge (instead of at origin)
• Low-Quality Image Placeholders — LQIP generation for lazy load

For a first pass, enable only CDN and Image Optimization. The page optimization service is powerful but introduces edge-side mutation that occasionally breaks themes — add it later once the basic flow is stable.

Step 3 — Switch DNS to the QUIC.cloud CNAME

Edge caching only engages once the domain resolves to QUIC.cloud's anycast IPs instead of your origin. The plugin generates a per-domain CNAME target in the QUIC.cloud dashboard — something like example-com.b-cdn.quic.cloud.

Two paths:

Option A — CNAME flattening at the apex (recommended). If the registrar supports ALIAS or ANAME records (Cloudflare DNS, Route 53, DNSimple), point the apex example.com at the QUIC.cloud target via ANAME. Add a www CNAME pointing at the same target.

Option B — A records to QUIC.cloud anycast IPs. If the DNS provider doesn't support ANAME, fetch the current anycast IPs from the QUIC.cloud dashboard and create A records. Refresh them quarterly — QUIC.cloud rotates IPs occasionally and stale A records cause silent fallback to origin.

After DNS propagation:

dig +short example.com

You should see an IP in the 192.0.66.0/24 range or similar QUIC.cloud anycast block, not your server's IP. Propagation is typically 5-15 minutes if you've kept TTL low beforehand.

Step 4 — Configure cache rules and exclusions

QUIC.cloud honors LSCache's Cache-Control and X-LiteSpeed-Tag headers automatically, so the cache key and invalidation logic from origin carry through to the edge. You generally don't need to configure edge rules separately.

Three exclusions worth setting explicitly in LiteSpeed Cache → CDN → CDN Settings:

• Bypass CDN for logged-in users — ON. The origin cache already handles logged-in separation, but pushing private content through the CDN consumes credits with no benefit.
• Original URLs — list any path that must hit origin: /wp-json/, /xmlrpc.php, custom REST endpoints. Default includes /wp-admin/ and /wp-login.php.
• HTML Cache TTL — leave at 8 hours. The tag-based purge handles freshness; TTL is only a safety net for cases where the purge ping fails.

Step 5 — Verify edge hits

Two checks confirm the CDN is actually serving:

curl -sI https://example.com/ | grep -iE 'server|x-qc-cache|cf-ray'

A served-from-edge response looks like:

server: QUIC.cloud
x-qc-cache: HIT

If you see Server: LiteSpeed instead, DNS hasn't switched yet or the request bypassed the edge — check the bypass rules and the resolved IP.

The first request after a purge returns x-qc-cache: MISS; subsequent requests within TTL return HIT. The QUIC.cloud dashboard shows per-PoP hit ratios, which is a more useful signal than a single curl — a healthy WordPress site averages 70-90% edge hit rate after the first day of warmup.

Step 6 — Image optimization workflow

Image optimization runs as a pull-based queue: the LSCache plugin sends image URLs to QUIC.cloud, which fetches the originals, generates WebP and (on supported tiers) AVIF variants, then notifies the plugin to switch the served URLs. Nothing is mutated on the origin server — the originals stay untouched in wp-content/uploads/.

In LiteSpeed Cache → Image Optimization → Image Optimization Settings:

• Auto Request Cron — ON (queues new uploads automatically)
• Optimize Original Images — ON
• Optimize Losslessly — OFF (lossy saves 30-50% more bytes for invisible quality loss on JPEGs; turn on only if a customer specifically complains)
• Create WebP Versions — ON
• WebP Replacement — ON (serves .webp to compatible browsers via <picture> or rewrite rules)

Queue depth is visible at Image Optimization → Image Optimization Summary. Initial runs on a site with 5,000 images take 6-24 hours depending on quota — QUIC.cloud rate- limits free tier accounts to a few hundred per hour to avoid abuse.

Step 7 — Monitor credits and bandwidth

QUIC.cloud bills on two separate meters: CDN bandwidth (per GB delivered from edge) and image optimization (per request). Both have free monthly allowances per domain, and overage is paid from a shared credit balance on the parent account.

In the QUIC.cloud dashboard, Dashboard → Usage shows month-to-date for each meter. For reseller billing, the Domains page lets you tag each domain with a customer identifier and export CSV usage per period.

Set a low-balance email alert under Dashboard → My Account → Notification Settings. The default is no alert — sites fall back to origin silently when credits exhaust, which is the right safety behavior but masks the billing issue until someone notices a higher origin bandwidth bill.

Common gotchas

• HTTP/3 still terminates at the edge. If you've also enabled HTTP/3 at origin, browsers now speak HTTP/3 to QUIC.cloud and QUIC.cloud speaks HTTP/2 to your server. That's expected — the user-visible benefit is at the edge and the origin connection is low-latency anyway.
• AutoSSL races. When DNS first switches to QUIC.cloud, cPanel's AutoSSL renewal cycle may fail because the HTTP-01 challenge no longer reaches the origin directly. QUIC.cloud passes through /.well-known/acme-challenge/ to origin transparently, so this resolves itself within one renewal cycle — but if AutoSSL fails loudly, check the bypass list before assuming a cert problem.
• WooCommerce sessions on the edge. QUIC.cloud respects the wc_session_* cookies set by WooCommerce and treats those requests as private — but ESI fragments need to be configured on origin (see the LSCache WordPress guide). Without ESI, cart pages never enter either cache and the CDN is wasted on WooCommerce.
• Page Rules don't work like Cloudflare. QUIC.cloud has no per-URL UI rule engine. All cache behavior is driven by the LSCache plugin's exclusion settings and the origin's Cache-Control headers. If you need URL-specific TTLs, set them in the plugin's Cache → Excludes tab.

Next steps

• If origin cache hit ratios are low, fix that first with the LSCache for WordPress guide — the CDN amplifies origin caching but can't substitute for it.
• For maximum performance, pair the CDN with HTTP/3 at origin so cache-miss requests benefit from the QUIC handshake too.
• Confirm your LiteSpeed license tier supports the worker count you need — QUIC.cloud doesn't reduce origin workers, only origin bandwidth.