Cloudflare's 526 erorr page visible for one second in a new Chrome session, at first load

I am getting a the 526 SSL erorr, only at first page load, in a new Google Chrome session, and only when accessing the domain root. The 526 page is visible only for up to one second, then the page automatically reloads to the normal homepage, with no other occurences in that session.

To simulate this issue, I wold open a new Google Chrome (latest version) incognito window and access the root (naked) domain. What do I first see? Cloudflare’s 526 SSL erorr page. For how long? about 1/2 seconds. The issue is happenong every single time, with no exceprtions, under these conditions. Changing “Block third-party cookies” setting before accessing naked domain does not make a difference. It is more about what Cloudflare decideds to “give” to the browser to initally dispaly.

The issue is not happening when accessing a specific page in similar conditions (eg., only with naked domain ( The issue is also happening on mobile version of Google Chrome too.

The issue can NOT be replicated in Microsoft Edge (latest version)
The issue can NOT be replicated in Mozilla Firefox (latest version)

So what is the actual problem? Well, a new visitor using Coogle Crome browser (desktop or mobile) allways sees the Cloudflare’s 526 error page for a second, before seeing the actual hompage, at first access of our root domain. The issue lies at the “border” between Cloudflare and Google Chrome. I could no longer submit this type of issue direcly to Cloudflare tehnical team, only post it here unfortunately.

The website is in Full (strict) mode, bun even so, I think that this is more likely a browser related issue that Coloudflare is unaware of, or perhaps they are serving something different to a request from a Google Chrome user agent, so that explains why in other browsers the issue can not be replicated.

As it turned out, the issue seems to have to do with the fact that in Google Chrome, when accessing “domainname. com”, in the conditions described in the first post, the browser will, wierdly, attempt to GET to “https: //www domainname com”. Of course I do not have anywhere a redirect to “www”. I have a CNAME in Cloudflare DNS management CNAME “www domainname com :norange: auto” and an A record “A domainname com :norange: auto”

I also have turned ON the following settings in Cloudflare for the “domainname com”:

  • :logopulse: SSL/TLS Full (strict) :ssl:
  • :logopulse: Always Use HTTPS :ssl:
  • :logopulse: Automatic HTTPS Rewrites :ssl:

So the browser will initialy make a GET request to “www” subdomain and recieve a :yellow_circle: 302 status code. Request URL: “https:// www domainname com/”, Referrer Policy: same-origin, cf-cache-status: DYNAMIC (data from DevTools Network Coogle Chrome)

I don’t now why Google crome will try to GET to “www” as tipyng in the Chrome’s omibox “domainname com” is triggering initially a GET request made to: Request URL: “https:// www domainname com/” that returns a :yellow_circle: 302 status code. Then the 526 Colodflare SSL erorr page displays for one second. Then the browser initiate a new request: Request URL: “https:// domainname com/” that returns a :green_circle: 200 status code and domainname com loads as it should.

After finding this out, my quick fix was to set a page rule in Cloudflare dashboard for the affected domain, to forward all “www” traffic towards the root domain (redirect the “www” subdomain to the apex domain):

:logodrop: www. domainname. com/*
Forwarding URL (Status Code: 301 - Permanent Redirect, Url: https:// domainname com/$1)

My conclusion upon now is that because of how Google Chromne initialy tryes to GET to “domainname com”, meaning it tryes to wroungfully GET to “www” :facepalm: I am forced to use a “www” forwarding page rule in Cloudflare to counteract that.

As a last note, the “no links” policy of this forum only made things harder for me in writing this post, forcing me to alter some text, insert extra spaces, removing the TLD dots :facepalm:

You can use code blocks to post domains like without them being turned into links.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.