Frequently Asked Questions

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.

If you are seeing an error message when setting up the QUIC.cloud nameservers for your domain, you can change the assigned servers. Log in to your my.quic.cloud account, navigate to DNS Zones, and select your domain. Then, click the link that says:

If your domain registrar does not accept the assigned nameservers, click here to change nameservers.

This will allow you to assign a different set of nameservers for your domain. Copy the new assigned nameservers and try to configure these with your domain registrar.

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.

No. Your content’s URL will use your website’s original domain.

QUIC.cloud CDN operates as a reverse proxy, and fetches requested resources from your site’s web server (aka the “origin server”). Any URL rewriting is handled internally so that the CDN may serve cached content from its network transparently, without altering the original URLs.

No. QUIC.cloud is a reverse proxy, and serves all content with your site’s original URLs. It is not compatible with third party CDN mapping plugins.

In the LiteSpeed Cache plugin’s CDN settings, the QUIC.cloud CDN setting is used to enable QUIC.cloud CDN functionality. This is the only setting you need to enable. The Use CDN Mapping setting is for CDNs that use a different URL to serve static content. QUIC.cloud does not make use of a CDN URL, thus mapping is not necessary.

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.

If you see an IP address mismatch error message on the Domain Settings page, it means that the IP address set on the Server IP field does not match the IP address on the main record in the DNS Zone for the domain.

To fix the error message look up your server’s IP address. You can find this on your site’s hosting or in your WordPress settings. Copy the IP address and paste it into the Server IP field at your QUIC.cloud Dashboard > My Domains > example.com > Settings > Server IP. Click the Save Changes button. The system will automatically update the main A record for the domain as well. Click DNS Zones > example.com and verify the correct IP address is set on all other DNS A records.

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.

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.

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.