Frequently Asked Questions

Yes. You must be registered at my.quic.cloud in order to use QUIC.cloud CDN.

All of them!

QUIC.cloud CDN acts as a reverse proxy content delivery network. It does not take the place of a web server, so your site must have its own. You can use any web server software. LiteSpeed Web Server, Apache, Nginx, OpenLiteSpeed, and others are all compatible with QUIC.cloud.

The LiteSpeed Cache plugin for WordPress (LSCWP) is the bridge that allows QUIC.cloud to work with any server.

One of the great benefits of QUIC.cloud CDN is that it opens up LSCWP caching functionality for everyone. Usually these functions are reserved for use with a LiteSpeed web server. However, QUIC.cloud CDN gives you the ability to cache your site with LSCWP, even if you are running nginx, Apache, or some other server software.

Not anymore. Server Push is an outdated technology and is no longer supported by many clients including the Chrome browser.

Yes. QUIC.cloud is capable of serving requests via HTTP/3 to browsers that also support the protocol. But unlike other CDNs, QUIC.cloud is also capable of making backend HTTP/3 connections! If your site’s origin server supports HTTP/3 (it does if you are running on LiteSpeed Web Server) and your visitor’s browser supports HTTP/3, then QUIC.cloud will serve your content end-to-end via HTTP/3. If either the origin server or the client cannot handle an HTTP/3 connection, QUIC.cloud will connect via HTTP/2 or HTTP/1 as appropriate.

QUIC was originally a Google effort to improve HTTP/2 by transporting it encrypted over UDP (as opposed to TCP). In 2016, the Internet Engineering Task Force (IETF) began working to standardize the protocol. Part of that process involved splitting QUIC into the transport and application protocols. For some time, the application protocol was referred to as HTTP-over-QUIC, but in November of 2018, the IETF announced that HTTP-over-QUIC would be called HTTP/3.

Any site using QUIC.cloud CDN is capable of HTTP/3 connections. You can verify this with the HTTP/3 Check tool. If your site does not appear to support QUIC or HTTP/3, check your QUIC.cloud Dashboard and make sure your domain is set up properly.

Yes, you can easily bypass the CDN if you need to. In your QUIC.cloud dashboard, navigate to the domain you want to bypass, click on the CDN tab, then select CDN Config in the left hand menu. Toggle Bypass CDN to ON.

Yes. QUIC.cloud will send one email notification to your account’s email address when you have used 80% of your available bandwidth.

If you don’t add more bandwidth to your domain, and you run out, you will receive another email notification alerting you that the CDN has been temporarily bypassed.

QUIC.cloud can get this information from WordPress via your LSCache plugin settings, but you can also manually set the IP address in your QUIC.cloud Dashboard, if you wish.

PoP stands for “Points of Presence.” A PoP is a location, referenced by IP address, where we have a CDN node. Our PoPs are located around the world. See the CDN Global Coverage Map for more information.

Yes. We maintain an IP list. You can use this list to populate your firewall’s allowlist, as some firewalls may block CDN IPs. This list is subject to change at any time without notice.

You will need to make sure the QUIC.cloud IPs in your firewall’s allowlist are up to date. If you are running LiteSpeed Web Server v5.4.12 or newer, this will be handled automatically. The same goes for Imunify360 and Bitninja. Automation through other means will be added in the future, but until then, if your security solution cannot automatically keep up to date with the IP changes, you will need to manually update the QUIC.cloud IPs in your allowlist. In this case, we recommend that you check the IP list daily. Learn more in our Knowledgebase.

Absolutely. We are always looking to expand and improve our network. If you have specific requests for PoP locations, feel free to join our Slack Community and post your ideas in the #quic_cloud_cdn channel

Yes and no.

It is required if you are using QUIC.cloud CDN, but it is not required if you are only using the Online Services (Image Optimization, Page Optimization, etc.).

DNS verification is our way of making sure that your DNS is configured correctly for use with QUIC.cloud CDN. During the test, we toggle the DNS to point your site to QUIC.cloud PoPs and then check whether it is indeed pointing to the PoPs. If successful, your site is considered Verified. We will automatically generate an SSL certificate (if you’ve enabled that option), and QUIC.cloud CDN will begin handling your domain’s traffic. If there is a failure at any point in the verification process, the DNS will be reverted back to your origin server. You can then fix your configuration and try again.

If your domain passed DNS Verification, then your DNS is most likely configured correctly. To be sure, try pinging your site twice:

1. First use your site’s domain (for example, example.com or www.example.com)
2. Then use the URL that QUIC.cloud provided to you (for example c12345.tier1.quicns.com)

The IP addresses returned from both pings should match.

Alternatively, visit LSCache Check, enter your URL, and look for the x-qc-pop response header. If it’s there, it means your site was accessed via a QUIC.cloud PoP, and your DNS is configured correctly.

No. This is expected behavior.

If you use a DNS Propagation Checker (like this one), and it shows a variety of different IP addresses, that is a good thing. Each of those IP addresses belongs to a QUIC.cloud PoP. When you see so many different IPs listed, it is proof that QUIC.cloud is serving your domain from locations all around the globe. QUIC.cloud automatically uses the visitor’s closest available PoP in order to speed up transmission of your site’s content.

You can see an up-to-date list of QUIC.cloud IP addresses here.

It is not required to use the root domain. Subdomains may be used, if you prefer.

To use your root (or apex) domain with QUIC.cloud, your DNS must support CNAME flattening or ANAME/ALIAS records. If your DNS provider does not support CNAME flattening, then the only way to use your root domain with QUIC.cloud is to switch your DNS provider. QUIC.cloud offers a free DNS service if you need one. Our knowledgebase has more information about DNS and QUIC.cloud CDN.

To use a subdomain with QUIC.cloud, you can use the CNAME method with your existing DNS provider. Or, you can switch to QUIC.cloud’s free built-in DNS service. Please see our knowledgebase for more information about all of your DNS options.

No. Other CDNs that allow you to use a subdomain are only using it for static content (images and other rarely-changing assets). QUIC.cloud functions as a reverse proxy in front of your entire site, and so the site itself must point to the CDN. This is what allows QUIC.cloud to reliably cache your site’s dynamic content on our global network, and to serve everything from cache in a locale-advantaged manner.

The simplest answer is that “it’s complicated.” Having multiple web apps at the same domain may or may not be problematic. Because the whole domain must be pointed to QUIC.cloud, the WordPress site will be fine, but any others at that domain could potentially experience caching issues, especially if they are running other web apps that use LSCache, or there are special rules in the .htaccess file that must be followed.

If possible, we recommend putting each site in its own subdomain (for example, blog.example.com instead of example.com/blog, or forum.example.com instead of example.com/forum). This way, you can point the WordPress site’s subdomain to QUIC.cloud without impacting any of the other sites living at that domain.

From time to time, QUIC.cloud IP addresses are blacklisted on reputation services like MxToolbox. This happens because reputation services will usually blacklist the entire subnetwork when an IP becomes problematic.

So, if a service or provider gets blacklisted for sending spam email, for example, and that server’s IP is in the same subnetwork as a QUIC.cloud IP,  the QUIC.cloud IP is also blacklisted automatically. This is why it is usually not possible to simply remove a single IP address from these blacklists.

This is nothing to worry about, as it does not affect your email service.

If a QUIC.cloud IP address is blacklisted, it has no impact on your email service whatsoever.

Your email service uses your origin server’s IP. You can take a look at the mail delivery SPF records to verify this. They should look something like v=spf1 a mx ip4:123.456.789.123 ~all. The numbers listed after ip4 will be your origin server’s IP address, and not a QUIC.cloud IP.

The only IP address that affects your mail delivery is your origin server’s IP address.

Yes. Under the Standard Plan, the QUIC.cloud dashboard allows you to enable and configure a wide array of security measures including:

• reCAPTCHA
• WordPress Brute Force Defense
• XML-RPC restrictions
• WordPress-specific security measures
• Customizable allow and block lists for access control.

While basic security measures are included with the Free Plan, these features are always enabled and are not configurable.

Please see Configuring CDN Security for more information about what is included with each plan.

No, you cannot generate an SSL Certificate via QUIC.cloud if you do not set up a CNAME record or switch to QUIC.cloud DNS, as instructed.

It normally takes up to a minute to generate an SSL Certificate. If it does not generate for you, please open a ticket.

Yes. QUIC.cloud has the ability to generate an SSL certificate for your site, manage the expiration, and keep it automatically up to date, but you may manage your own SSL if you prefer. Visit your QUIC.cloud Dashboard, and add the Certificate and Private Key in the CDN Config section. If you decide to use QUIC.cloud’s automatic SSL feature, we still strongly recommend that you keep your own certificate up to date on your origin server. This is required if you are using QUIC.cloud’s WordPress optimization services, and it allows end-to-end secure connections for the CDN.

QUIC.cloud uses servers around the world to reduce the physical distance requests must travel. Additionally, QUIC.cloud can cache dynamic content at the CDN level, unlike other CDNs which must retrieve all dynamic requests from the origin server. CDN-level caching not only improves QUIC.cloud’s overall bandwidth speed, but it also minimizes the number of requests to the origin server.

By default, QUIC.cloud caches your site’s dynamically generated pages. This cache is controlled via the LiteSpeed Cache plugin for WordPress. QUIC.cloud can also cache your site’s static content. Be sure to set Static Cache to ON in your QUIC.cloud Dashboard‘s CDN Config area.

Yes. The crawler included in the LiteSpeed Cache for WordPress plugin will populate the cache at the origin server (but only if it is a LiteSpeed server), and also the cache at the QUIC.cloud PoP closest to the origin server.

Under the current CDN cache policy, pages are stored at a PoP for 24 hours from the last access. So, pages that don’t see much traffic will be removed from the PoP’s cache after about a day, but pages that are accessed at least once daily will remain in CDN cache up to 7 days.

Future plans include tiered regional caching, which will increase the CDN cache hit rate and allow us to cache pages in a nearby node longer term.

Please note: if the General > Server IP option is set in the LSCache plugin, the crawler will directly populate the cache for the server at that IP, essentially bypassing QUIC.cloud. If you wish for the local QUIC.cloud PoP to be included in your site’s cache crawl, then you need to leave Site IP blank.

Yes, however this should not be necessary under normal circumstances. The CDN cache is managed by the LiteSpeed Cache plugin for WordPress, and is sophisticated enough to know when content has changed and requires purging. That said, if you wish to purge the CDN cache manually, visit your QUIC.cloud Dashboard, and press the Purge All CDN Cache button in the Domain Overview section.

Auto Redirect www/non-www speeds up response time by caching redirect requests.

Here’s how it works:

1. The browser sends a request for www.example.com to QUIC.cloud CDN.
2. QUIC.cloud sends the www.example.com request to your origin server.
3. The origin server returns a response, indicating that the www.example.com request was redirected to example.com (the non-www domain).
4. QUIC.cloud returns this redirect response to the browser and caches the response at the PoP level.
5. The next time a www.example.com request is received, QUIC.cloud automatically redirects to example.com, saving a round trip to the origin server.

This works if the redirect is in the opposite direction, too (example.com redirecting to www.example.com).

Under the current CDN cache policy, pages are stored at a PoP for 24 hours from the last access, up to 7 days total.