Adding blog post about the cloudflare redirect loop error

This commit is contained in:
Elia el Lazkani 2020-01-27 22:50:31 +01:00 committed by Elia El Lazkani
parent fca4c3e66f
commit aba19e6f1c
No known key found for this signature in database
GPG key ID: FBD81F2B1F488C2B
4 changed files with 104 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 123 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

View file

@ -0,0 +1,104 @@
.. title: My path down the road of cloudflare's redirect loop
.. date: 2020-01-27 22:00:00
.. slug: my_path_down_the_road_of_cloudflare_s_redirect_loop
.. updated: 2020-01-27 22:00:00
.. status: published
.. tags: misc, cloudflare, cdn
.. category: misc
.. authors: Elia El Lazkani
.. description: I have had issues with cloudflare's CDN causing redirect loop errors, here's how I solved it.
.. type: text
I have used **Cloudflare** as my *DNS manager* for years, specifically because it offers **API** that works with **certbot**. This setup has worked very well for me so far.
The only thing that kept bothering me is that every time I turn on the *CDN* capability on my **Cloudflare** , I get a loor error. That's weird.
.. TEASER_END
Setup
=====
Let's talk about my setup for a little bit. I use **certbot** to generate and maintain my fleet of certificates.
I use **Nginx** as a web-server.
Let's say I want to host a static content off of my server. My **nginx** configuration would look something like the following.
.. code:: text
server {
listen 443 ssl;
server_name server.example.com;
ssl_certificate /path/to/the/fullchain.pem;
ssl_certificate_key /path/to/the/privkey.pem;
root /path/to/data/root/;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
This is a static site, of course. Now you may ask about *non-SSL*. Well, I don't do *non-SSL*.
In other words, I have something like this in my config.
.. code:: text
server {
listen 80;
server_name _;
location / {
return 301 https://$host$request_uri;
}
}
So, all *http* traffic gets redirected to *https*.
Problem
=======
Considering the regular setup above, once I enable the "proxy" feature of **Cloudflare** I get the following error.
.. thumbnail:: /images/my_path_down_the_road_of_cloudflare_s_redirect_loop/too_many_redirects.png
:align: center
:alt: Too Many Redirects Error
That baffled me for a bit. There is no reason for this to happen. I decided to dig deeper.
Solution
========
As I was digging through the **Cloudflare** configuration, I stumbled upon this page.
.. thumbnail:: /images/my_path_down_the_road_of_cloudflare_s_redirect_loop/flexible_encryption.png
:align: center
:alt: Flexible Encryption
This is interesting. It says that the connection is encrypted between the broswer and **Cloudflare**.
Does that mean that between **Cloudflare** and my server, the connection is unencrypted ?
If that's the case, it means that the request coming from **Cloudflare** to my server is coming on *http*.
If it is coming on *http*, it is getting redirected to *https* which goes back to **Cloudflare** and so on.
::
THIS IS IT ! I FOUND MY ANSWER...
Alright, let's move this to what they call "Full Encryption", which calls my server on *https* as it should.
.. thumbnail:: /images/my_path_down_the_road_of_cloudflare_s_redirect_loop/full_encryption.png
:align: center
:alt: Full Encryption
After this change, all the errors cleared up and got my blog up and running again.