Adding Cloudflare in front of a website hosted by GitLab Pages is simple, but sometimes it does not work as expected. Using a custom domain (e.g. your-website.org) with GitLab Pages and proxing it through Cloudfare DNS could result in an infinite redirect loop.

The setup

A site has been published on GitLab Pages, following the GitLab instructions, and for which a custom domain name has been added in GitLab Pages (e.g. your-website.org) together with an SSL certificate to expose it via HTTPS. The domain DNS is managed by Cloudflare where an A DNS record (with proxy mode on) is pointing to GitLab Pages IP 35.185.44.232.

The error

In some cases, using the above configuration, loading https://your-website.org with Chrome may result in an error.

This page isn’t working right now your-website.org redirected you too many times. ERR_TOO_MANY_REDIRECTS

While Firefox blames cookies.

The page isn’t redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete. This problem can sometimes be caused by disabling or refusing to accept cookies

And if you look at the browser’s network tab you can see a long sequence of GET requests, ending with an NS_ERROR_REDIRECT_LOOP error.

This happens because the HTTP response returns the 301 Moved Permanently' status code with the Location: https://your-website.org’ header, which forces your browser to reload the page, ending up in an infinite loop.

You can try removing cookies or making the same call using cURL but response will be the same (301).

Troubleshooting

A clue to what is happening is provided by the Location header. In fact, if we try to make a GET call to a page on the same domain, e.g. https://your-website.org/not-exists, that does not exist. Even though the page is missing, the HTTP response will always return a 301 status, and in the location field we will find Location: https://your-website.org/not-exists.

From this behaviour we can understand that the server is redirecting us before the requested resource is read, otherwise we would have received a 404 status. Furthermore, since the redirection is always to the same resource, the behaviour seems to be linked to a change in the way requests are made.

Client->Cloudflare request

Cloudflare’s proxy mode guarantees that all user requests are protected by SSL/TLS and therefore always over HTTPS, but only if the user requests it. In fact, only when Cloudflare’s Always use HTTPS option is enabled, all requests are redirected to HTTPS. If it is not enabled, the client’s HTTP request remains HTTP, at least between the client and Cloudflare. What happens between Cloudflare and GitLab follows a different logic.

Cloudflare->origin request

Unless configured differently, Cloudflare chooses ‘independently’ how to connect to the origin server. The type of connection used between Cloudflare and the origin is independent of the one used by the client to make the request. In some cases this automation can cause problems and it is better to configure it manually in the Custom SSL/TLS section. Cloudflare offers five different levels of encryption to use to connect to the origin server:

Off (no encryption) : No encryption is used for traffic between browsers and Cloudflare or between Cloudflare and origins. Everything is cleartext HTTP.

Flexible : Traffic from browsers to Cloudflare can be encrypted via HTTPS, but traffic from Cloudflare to the origin server is not. This mode is common for origins that do not support TLS, though upgrading the origin configuration is recommended whenever possible.

Full : Cloudflare matches the browser request protocol when connecting to the origin. If the browser uses HTTP, Cloudflare connects to the origin via HTTP; if HTTPS, Cloudflare uses HTTPS without validating the origin’s certificate. This mode is common for origins that use self-signed or otherwise invalid certificates.

Full (strict) : Similar to Full Mode, but with added validation of the origin server’s certificate, which can be issued by a public CA like Let’s Encrypt or by Cloudflare Origin CA.

Strict (SSL-Only Origin Pull) : Regardless of whether the browser-to-Cloudflare connection uses HTTP or HTTPS, Cloudflare always connects to the origin over HTTPS with certificate validation.

GitLab Pages response

GitLab Pages options include Force HTTPS which, when enabled, redirects all HTTP requests to HTTP by sending a 301 status code.

Since redirecting to HTTP is exactly what we get, this seems to be the cause of the problem.

What is happening

For some reason, Cloudflare is making requests to the GitLab site using HTTP but, since Force HTTPS is enabled in GitLab, GitLab is responding by redirecting the request to HTTPS. And since this behaviour is independent of the type of request made by the client, the redirection always occurs, generating the loop.

How to fix it

The solution to the problem is simple, just set the encryption used by Cloudflare to the origin (GitLab Pages) in Full or Full (strict) mode. As shown in the Cloudflare documentation above, using Full Cloudflare matches the browser request protocol when connecting to the origin - in the case of strict Cloudflare will also validate the certificate received from the origin.

Once this change has been made, if Cloudflare receives an HTTP request, it will be forwarded to GitLab Pages using the same protocol. Once it reaches GitLab, a response will be generated with a redirection to the HTTPS version of the page. If, on the other hand, the request received by Cloudflare is an HTTPS one, this protocol will also be used to connect to GitLab where the correct response will be generated and sent to the client.

Final note

Cloudflare has a troubleshooting page for to the “too many redirects” topic and GitLab documentation has a tiny note explaining that:

If you use Cloudflare CDN in front of GitLab Pages, make sure to set the SSL connection setting to full instead of flexible.

If I wrote this post, and if you have read it all, it means that neither of us has read that note.