Setting up Cloudflare

Last night I set up Cloudflare for my website, mostly to get https. Not having many cacheing needs, that was not a concern. Along the way though, I did run into a number of annoyances so hopefully this helps you avoid those.

Undiscovered Subdomains

After signing up with Cloudflare, it scans your site for its content and subdomains. It'll find the usual subdomains, but if you have unusual ones you have to add them on the control panel.

Otherwise there will be problems with the nameserver settings, and even though your subdomains will still be showing at their IP Address, you'll see errors when using the URL.

Note: You just need to add the subdomain here, like blog or demo, and not the full URL. Chances are your subdomain is on the same IP Address as your website, but if not, check your hosting account.

Changing Nameservers

Once you've Cloudflare configured, change your Nameserver settings with your domain provider. I use Godaddy, but whatever you use you'll need to change your settings to point to the ones Cloudflare uses, which in my case are the following:

Redirecting http to https

The final step is to always serve your pages using https. I found that the simplest way is to use Nginx with the http_x_forwarded_proto option. You'll need to configure this in all your virtual host files.

server {
    listen      80;
    server_name     example.con;

    if ($http_x_forwarded_proto = "http") {
         return 301 https://$server_name$request_uri;

        location / {
        root /path/to/files;
        index index.html index.html; 

Git and Mercurial Problems

One problem I have yet to solve is that of a subdomain hosting git and mercurial repositories. For git repositories I am now getting the following error on the command line:

$ git pull
fatal: unable to access 'https://git.repo.url':
gnutls_handshake() failed: Handshake failed

For Mercurial repositories it is something similar:

$ hg pull
abort: error: _ssl.c:510: error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error

The workaround currently is to replace the URL in the request with the IP Address, but as I'm not happy with that, it's a problem I'll look into over the weekend.