CloudFlare is a "magical" multi-purpose website performance & security service, which works on DNS level. It can be used as a kind of Content Delivery Network and as a protection against Denial Of Service Attacks. It is also popular choice to get an SSL certificate for your domain without costs and hustle.
Pricing and signup¶
Integrating CloudFlare with fortrabbit¶
There is no technical connection between CloudFlare and fortrabbit. CloudFlare will be in between of your DNS provider and fortrabbit — think of it as proxy. You will set your name-servers (NS) to point to CloudFlare.
In the following example you first register your domain with your domain provider, then point it to fortrabbit using our standard settings, then CloudFlare will scan the DNS records for you:
- Make sure to have a domain registered with a domain provider
- Make sure to have added the domain in the fortrabbit Dashboard
- Route the domain using our instructions still with your old DNS provider
- Set up the domain with CloudFlare
- CloudFlare will scan and use the DNS settings already in place
You might also start with a fresh domain from scratch within CloudFlare. Then CloudFlare will act as your DNS provider. Enter the DNS settings from the fortrabbit Dashboard with CloudFlare.
Each domain on CloudFlare comes with a bunch of settings. One is called "Crypto" and is about SSL. Your goal is that the whole communication between the user of your website is encrypted of course. Now, CloudFlare, as described above, is a proxy between your user and fortrabbit. The first lap from the user to CloudFlare is secured by default, but what about the the next one, between CloudFlare and fortrabbit?
┌──────┐ ┌────────────┐ ┌────────────┐ │ User ├─HTTPS─▶ CloudFlare ├─ ? HTTPS ? ─▶ fortrabbit │ └──────┘ └────────────┘ └────────────┘
CloudFlare is the domain end point for the user. CloudFlare itself will actually talk to the App URL. The connection between the App and CloudFlare should also be encrypted.
The App URL has HTTPS, so you can and should set SSL to full to ensure end-to-end encryption. The default flexible setting is not enough (as we think). "Full (strict)" mode will not work but is not necessary.
CloudFlare DNS and fortrabbit Dashboard Status¶
CloudFlare is a bit of blackbox, DNS-wise. When you'll visit a domain in the fortrabbit Dashboard that is routed via CloudFlare a definite answer is not possible. The Dashboard is aware of many CloudFlare IPs, so it will likely guess that the domain is routed via CloudFlare. Still you might see an error, while in fact the domain is routed correctly.
CloudFlare SSL VS Let's Encrypt¶
Many fortrabbit clients have used CloudFlare to get SSL, see our HTTPS article as well, for their own custom domain without the need to book and setup a custom cert here. Now, fortrabbit also offers free SSL certificates via (free and zero-config) Let's Encrypt. So if that is your aim, you'll might not need CloudFlare.
CloudFlare and 2nd level subdomains¶
When you are seeing an
SSL_ERROR_NO_CYPHER_OVERLAP error. But you think you have set up everything correctly, check the domain you are trying to route. Is is a second level of a subdomain like
dev.www.example.com? If so, further actions might be required, please see the CloudFlare help.
Other reasons to use CloudFlare¶
While free SSL has become a commodity, there are other reasons to use CloudFlare:
- Enhanced DDoS protection
- CNAME Flattening for naked domains (naked domain directly with fortrabbit)
- Domain analytics
Using CloudFlare for naked domains¶
So, we tried to convince you that a naked domain (a domain without www or other prefix) is not necessary at all, but you still want a naked domain to be your primary domain instead of just a forward with fortrabbit: CloudFlare can help you here as well. You need to set two things in the CloudFlare Dashboard to make this work:
- DNS Settings: choose CNAME and enter the naked as Name and the App URL as value (this is only possible with CloudFlare black magic)
- Page Rules:
https://domainname.comusing 301 (that will catch if someone enters your domain with www)
Prevent direct access¶
You may want to assure all traffic is routed through CloudFlare. This is important to secure 360 DDoS protection. You'll basically disable the App URL to be accessible. To block direct access and whitelist only CloudFlare's IPs, extend your
.htaccess file with the following rules:
ErrorDocument 403 "Not Allowed" Deny from all ### Cloudflare IPs ### Allow from 188.8.131.52/22 Allow from 184.108.40.206/22 Allow from 220.127.116.11/22 Allow from 18.104.22.168/12 Allow from 22.214.171.124/18 Allow from 126.96.36.199/22 Allow from 188.8.131.52/18 Allow from 184.108.40.206/15 Allow from 220.127.116.11/13 Allow from 18.104.22.168/20 Allow from 22.214.171.124/20 Allow from 126.96.36.199/20 Allow from 188.8.131.52/22 Allow from 184.108.40.206/17 Allow from 2400:cb00::/32 Allow from 2405:8100::/32 Allow from 2405:b500::/32 Allow from 2606:4700::/32 Allow from 2803:f800::/32 Allow from 2c0f:f248::/32 Allow from 2a06:98c0::/29
As the IP ranges might change from time to time, you should update them on a regular basis. Here you can find the current IP ranges. This little script helps you to keep your whitelist up-to-date, ideally you run it during deployment.
Alternatives to CloudFlare¶
CloudFlare is a magical package of different services all combined and streamlined in a single offering. Mind: with using CloudFlare, you make yourself dependent that this critical component (DNS/NS)) of your infrastructure is working correctly. It's another SPOF that makes your setup more complex and that can fail. In overall, it's likely more likely that your website will stay up with CloudFlare enabled.
Some of our clients prefer separation of services, instead of CloudFlare, they'll might use dedicated services for DNS/domain and CDN.