Cloudflare is a "magical" multi-purpose website performance & security service, which works at the 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 a popular choice to get SSL certificates for your domain without the costs and hassle.
There is no technical connection between Cloudflare and fortrabbit. Cloudflare will sit in between your DNS provider and fortrabbit — think of it as a proxy. You will set your nameservers (NS records) 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 endpoint 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 is a bit of black box, DNS-wise. When you visit a domain in the fortrabbit Dashboard that is routed via Cloudflare an accurate response is not possible. The Dashboard is aware of many Cloudflare IPs, so it will likely guess that the domain is routed via Cloudflare. But you might still see an error, even if the domain is in fact routed correctly.
Many fortrabbit clients have used Cloudflare to get SSL (see our HTTPS article) for their own custom domain, without the need to book and set up 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 might not need Cloudflare.
If you see 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 it a second level of a subdomain like
dev.www.example.com? If so, further actions might be required: please see the Cloudflare help.
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
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 domain 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 someone entering your domain with www)
You may want to ensure 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 184.108.40.206/22 Allow from 220.127.116.11/22 Allow from 18.104.22.168/22 Allow from 22.214.171.124/12 Allow from 126.96.36.199/18 Allow from 188.8.131.52/22 Allow from 184.108.40.206/18 Allow from 220.127.116.11/15 Allow from 18.104.22.168/13 Allow from 22.214.171.124/20 Allow from 126.96.36.199/20 Allow from 188.8.131.52/20 Allow from 184.108.40.206/22 Allow from 220.127.116.11/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: you should ideally run it during deployment.
Cloudflare is a magical package of different services all combined and streamlined in a single offering. Mind: by using Cloudflare, you make yourself dependent that this critical component (DNS/NS)) of your infrastructure is working correctly. It's another point of failure that makes your setup more complex. But overall, it's more likely that your website will stay up with Cloudflare enabled.
Some of our clients prefer a separation of services. Instead of Cloudflare, they might use dedicated services for DNS/domain and CDN.