Support
How to use CDN with CloudFlare
Important note
This tutorial assumes you have already created a pull zone.
What is CloudFlare
CloudFlare is a free system that acts as a proxy between your visitors and our server. By acting as a proxy, CloudFlare caches content for your site, which lowers the number of requests to our servers, but still allows visitors to access your site.
What is CDN
CDN stands for Content Delivery Network, and it works by acting as a reverse proxy that caches all your static contents and serves them to your website visitors from servers spread across the globe, that lowers the number of requests sent to your servers to zero at any given moment as long as the cached files are neither expired nor purged from the network. When the static contents are served to your website visitors from servers that are closer to them than your web server, the website load speed increases which provides a better user experience along with leveraging load off of your web server
The conflicts
First Conflict
The way CloudFlare works includes appending cookies and custom expiry headers that look like this:
|
1 2 3 4 5 6 7 8 9 |
sh-4.1$ curl -I domain.com
HTTP/1.1 406 Not Acceptable
Server: cloudflare-nginx
Date: Tue, 14 Aug 2012 14:31:59 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding,Cookie,User-Agent
Expires: Wed, 15 Aug 2012 14:31:59 GMT
Set-Cookie: __cfduid=de8b7126ad3841cd0da33c69651231c901344954719; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.domain.com |
When these cookies and headers are sent to our CDN Network, it causes a conflict that prevents us from properly caching your static assets. That results into very low cache hit percentage along with an increased number of requests being sent to CloudFlare, which will negatively affect the load speed of your website.
Second Conflict
CloudFlare automatically utilizes a load balancer, which dynamically changes the IP address of your website. While this is usually not an issue, but as our system depends on matching the IP address of the origin website with the FQDN/Domain/URL, it will cause a conflict which will result into our servers unable to fetch and cache your static contents and a 502 Bad Gateway error to occur.
The solution for the first conflict
NetDNA and CloudFlare worked together to offer a permanent solution for the first conflict. If you look at the screenshot below, you will see that next to each host configured in CloudFlare, there’s a little Cloud Icon.
When the icon is orange, it indicates that CloudFlare functionality is enabled for this hostname, if it’s dimmed/grey, it indicates that CloudFlare is disabled. CloudFlare automatically detects any NetDNA URL and permanently and irreversibly disables all CloudFlare proxy/functionality on any CNAME pointing to it. That means once you create your Custom Domain CNAME, you’re good to go on the CloudFlare end.
However, should you need to use the Temporary CDN URL. There’s a way: Create a CNAME Record and call it “origin” for example, and set it as an alias of your domain name. So it’s like the screenshot below.
And make sure the CloudFlare Acceleration is disabled by clicking the Orange Cloud Icon to turn it grey.
PS: It takes 5 to 10 minutes for enabling/disabling CloudFlare to globally update. Also do not forget to click the “I’m done entering my DNS records” button after you’ve made changes to your DNS Zone File.
The solution for the Second Conflict
In the past, we used to have Pull Zone 2.0 which utilized Apache Traffic Server to overcome the Dynamic IP problem caused by CloudFlare, Amazon AWS, and any other Load Balancing Technique. Apache Traffic Server had its problems, and lacked support for GZip compression. So we re-invented the Pull Zone to add an option for Dynamic IP Resolution, which can be enabled by any of our support staff members. Just send an email to [email protected] ( or maxcdn.com, or cloudcache.com ) and we will enable the option for your Pull Zone.