I'm going to answer this one, to share information on how I just did it. One issue will remain, but that will be raised in a separate question.
The first thing is to understand the URL layout which CloudFlare/Railgun will require. You or your hoster will create A records in DNS for all but one of these, each of them pointing to your server IP.
There's an order in which these records should be created, which your hoster will specify, in order to check all is well before aetting the CloudFlare service to be fully active for visitors to your site. So don't just go ahead from this list!
- Your main site, which will remain un-accelerated, but is a necessary DNS reference, and fallback if you disconnect CloudFlare. We'll call that domain.com.
- The access subdomain, where CloudFlare/Railgun retrieves content from your site in order to accelerate it. This will be cloudflare-source.domain.com, or similar if your hoster differs.
- if you're going to need SSL (https) to protect your Craft CP admin, you'll need a non-CloudFlare url to allow this, unless you're using one of the non-free versions of CloudFlare which allow SSL. Let's call this secure.domain.com.
- Notice that secure.domain.com on https/SSL can also be what you'd use to shelter e-commerce pages, but be very careful here. Unless you want to be required to go through a process of certifying PCI compliance, you'll want to use an actually self-safe e-commerce solution like Stripe.js, which handles customer and credit card data so that they are never sent to your server. The secure page set up here just adds security against mistakes, and helps build customer confidence by showing visibly that everything is protected by SSL.
- Any other subdomains such as a staging server will need to be on the same domain DNS record set, and also controlled by your server's virtual hosting config to arrive at the proper html folders on your site.
- Finally, and as mentioned, only after all the CloudFlare arrangements have been verified operating as your hoster show you to do, then a final DNS record will be added, by you or them depending on who's managing DNS. This will be a CNAME record aliasing www.domain.com, and it will point not to your site, but to the CloudFlare URL you'll be given, something like www.domain.com.xyz.cloudflare.net.
Ok. Notice that the CNAME alias is from www.domain.com. Your hoster will give you a set of prefix rules to go in your public Craft directory's .htaccess file, above the handling which calls Craft itself. If you have special rules there to cause automatic switching to SSL for the Craft CP, a small portion of those will need to go before the CloudFlare additions. I'll cover that in another question/answer on automatic SSL itself, updating an earlier post to one of the cookbooks, and as setup has slightly changed.
The result of the DNS and .htaccess additions is that your site will now always redirect visitors to www.domain.com even if they originally linked simply domain.com. As you can see, www.domain.com is aliased by the CNAME record to call CloudFlare rather than your site directly, and that's how the speed-up caching is applied.
Railgun will also operate on this URL once you turn it on from your CloudFlare control panel, the one which will have been set up for you by your hosting provider. You want to let them do that, as it is different and differently connected than one which would result from you signing up to CloudFlare independently, thus enabling your hoster's service.
Then you can see why the extra cloudflare-source DNS access is needed. Your main site will refer to www.domain.com, which comes from CloudFlare. CloudFlare must then get its picture of your site from somewhere else, and cloudflare-source.domain.com is that place.
Now that we have CloudFlare arranged via DNS and .htaccess, what do you need to do in Craft configuration to properly use it? As it turns out, not very much.
You need to refer Craft to the now-required www.domain.com wherever it needs reference to your site, rather than domain.com. In particular, the constant siteUrl needs to be set this way You can do that in the CP General configuration page, and/or as a definition in general.php.
Thus if you are not using languages (Locale on Craft Pro), in general.php you would set:
'siteUrl' => 'http://www.domain.com/',
while if you are using languages you would in general.php set the siteUrl array by the same principle, according to the languages on your site. This example is for English, Russian, and Swedish:
'siteUrl' => array(
'en' => 'http://www.domain.com/en/',
'ru' => 'http://www.domain.com/ru/',
'sv' => 'http://www.domain.com/sv/',
Several such arrays can be used individually as ever within a multi-site configuration, covering staging servers and so forth if you use that method. With or without multisite, if you've set your staging server as its own subdomain, then that will automatically bypass CloudFlare/Railgun for staging, which is very likely what you'd prefer.
Lastly, if you are using Craft Pro languages (Locale), you'll need to copy the fully equipped main site .htaccess to each of the language folders on the html site, so that they will respond appropriately. Not an option, and one of those fun ways to go wrong with languages, which when set up properly, are on Craft very easy and practical to work with.
How much improvement do you gain, from setting this up?
It can be quite dramatic.
On initial Pingdom testing and a site of not quite medium complexity, I'm seeing >5x improvement monitored in the US: from 2.5 seconds to 0.3 seconds for full all-images page loads, that important first customer access to your site.
Going overseas, CloudFlare is making practical a European customer's site from a single server base at Arcustech in the US. The same ordinary first-load pages go from 3 seconds to under 0.5 seconds. A difficult page with video players on it goes from around 25 seconds to around 1.7 seconds complete, both of these in Amsterdam from Minneapolis servers. The delay on the slow page is due to the video player background loading of libraries, so the screen view comes up more rapidly, but you can see it would be unusable without CloudFlare.
You can see that the CloudFlare-amplified service is as if it was local in Amsterdam. Across Europe one can see via Pingdom that not all areas will be as fast, but with the distribution of CloudFlare edge servers, all will be practical; 1-second pages say instead of half-second, and a little more for the video page, but by use of player-assisted 'poster' images it comes up visually much more quickly than it completes, so a few seconds will be fine there also.
These figures are assuming the caches are full at the edge servers. The very first access will be slower, if helped by CloudFlare's excellent connections, as always with a cache.
How much Railgun adds, for which we take this special configuration's effort, has to be complex. If you are running CNN-sized pages, it will measurably help a lot, as big boys and girls are using it, as well as other edge caches with similar (and very expensive) features. If you are running small pages, most of the time it will not be so visible. In between, in between.
However, I suspect Railgun is likely to speed up first-viewer-on-empty-edge-cache page speed also, due to its keepalive single connection and compressed, high-availability path. Similarly, it should help unexpectedly more than usual whenever there is network congestion and extended latency, which as anyone who uses or monitors them knows certainly happens a lot on transoceanic paths. As we note with the Netflix wars bringing it to visibility, it's not happening a little within North America itself. Edge caching and delta compression sending only in-page differences is clearly a way to insure and proceed, when it is free as in these Arcustech-type arrangements; at least I feel so for my present and future customers.