Cloudflare Error 520 for GoDaddy Managed WordPress site

We operate three WordPress sites via a GoDaddy Managed WordPress subscription.

For two of those sites (completetheorytest.co.uk and thestudiosws15.com) we use CF caching and SSL certificates and we have recently increasingly experienced 520 errors when accessing the sites. If we refresh the page we will (after 1 or maybe 2 refresh attempts) usually get the full site displayed.

I’ve chatted with GoDaddy about this at length and they insist that there is no apparent error at their side and if we disable CF caching and SLL (reverting to a standard http connection) then no issues are apparent.

https://thestudiosws15.com/cdn-cgi/trace yields:
fl=71f681
h=thestudiosws15.com
ip=92.0.76.249
ts=1631145187.817
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
colo=FRA
http=http/3
loc=GB
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off

A sample Ray ID is:
Ray ID: 68bc20d6ae49dfcf • 2021-09-08 23:59:02 UTC

Does anyone have any suggestions or experience of similar issues and solutions?

TIA

Tim

So as part of https://community.cloudflare.com/t/random-520-errors/ we fixed an issue with origins silently ending a keepalive connection that was causing very rare 520 errors.

Thus we recommend testing again - if you still see 520s - make sure you follow the guidance in our community tip here:

1 Like

Thanks Simon.

Unfortunately, the issue does persist and I have already followed (in so far as it is possible, in combination with Godaddy support via chat) the tips to which you referred.

I have collected the HAR files mentioned, but can’t contact Cloudflare support because those domains use a free CF plan (I see at least a few mentions of the issue “going away” as soon as the plan is upgraded to “Pro” - do you have any feelings or thoughts on that?).

In case they’re useful, the HAR files are at:

With CF caching and SSL: thestudiosws15.com (with CF caching and SSL active).har - Google Drive

Without CF caching and SSL: thestudiosws15.com (WITHOUT CF caching and SSL active).har - Google Drive

Tim

Hi Tim,

The fix I mentioned ensures that the Free user issue with keepalives is now fixed. There is no requirement to upgrade to avoid 520 errors - this was a software bug.

If the errors persist beyond this bugfix, you need to check your origin server error logs when the errors happen to understand what your origin is doing to cause us to return a 520. Most common cause is the origin resetting the TCP connection to Cloudflare - it’s impossible for Cloudflare to know why that happens - which is why checking your origin error logs is important.

1 Like

ATM, GoDaddy say to move forward with them we’d have to move the domain name servers to them and purchase an SSL certificate from them to apply to the managed WordPress site(s). The former doesn’t seem necessary (could just turn off CF proxying and caching), but I could trt the latter.

The site is currently operating in CF’s “Flexible” SSL mode - which I know isn’t ideal, so maybe adding a GoDaddy SSL certificate and then (presuming CF caching remains on) try switching CF SSL mode to “Full” or (if that doesn’t work) “Off”.

But, AFAIK, this shouldn’t be necessary and what we have in place should (and used to) work - else why would it be offered by CF?

Tim

You definitely should not be doing this as you noted. This should be “Full (Strict)”. As for an SSL cert, you could buy one from GoDaddy but there are also free providers like Let’s Encrypt. If you use either one you can set that to “Full (Strict)” and actually have a fully encrypted site.

As for moving off Cloudflare, that’s honestly your choice. Cloudflare offers a lot of benefits but of course, this 520 issue wasn’t ideal (but at least it’s fixed now). It’s up to you on that though. If you did stay, it’ll work with no problems (just pls get that ssl issue fixed)

Thanks for your advice - don’t think GD allow third party SSL certificates for managed wordpress sites.

Error 520: web server returns an unknown error

Error 520 occurs when the origin server returns an empty, unknown, or unexpected response to Cloudflare.

Resolution

A quick workaround while further investigating 520 errors is to either grey cloud the DNS record in the Cloudflare DNS app or temporarily pause Cloudflare.

Contact your hosting provider or site administrator and request a review of your origin web server error logs for crashes and to check for these common causes:

  • Origin web server application crashes
  • Cloudflare IPs not allowed at your origin
  • Headers exceeding 16 KB (typically due to too many cookies)
  • An empty response from the origin web server that lacks an HTTP status code or response body
  • Missing response headers or origin web server not returning proper HTTP error responses

520 errors are prevalent with certain PHP applications that crash the origin web server.

If 520 errors continue after contacting your hosting provider or site administrator, provide the following information to Cloudflare Support:

Have you tried those troubleshooting steps?

Spent another couple of hours chatting with GD and only served to repeat the process already gone through on two previous chats.

I’ve included the test from that chat below - I’m trying to get the issue escalated within GD so that CF and GD might talk to each other to resolve what appears to be a reasonably widespread issue rather than each simply blaming the other and leaving customers in the middle going nowhere…

23:19, Sep 9 GD: Hi, my name is GD. May I know to whom am I chatting with? How may I help you with your concern?

23:19, Sep 9 TK: Hi GD, my name is TK

23:20, Sep 9 TK: This is the third day that I’ve contacted GoDaddy about an ongoing issue whereby Cloudflare can’t reliably present https pages of GoDaddy Managed WordPress pages and instead shows Error 520 approximately 25% of the time a connection is attempted.

23:21, Sep 9 TK: You’ll find that I’m not the only one of your customers that is experiencing this same issue: Godaddy / Cloudflare 520 error (recent change) and Cloudflare Error 520 for GoDaddy Managed WordPress site - #8 by AppleSlayer

23:22, Sep 9 TK: Previous advice from GoDaddy was to move DNS to GD (from CF) thereby disabling CF caching and add an SSL certificate from GD. But this shouldn’t be necessary

23:23, Sep 9 TK: You’ll see from Godaddy / Cloudflare 520 error (recent change) - #51 by simon that Simon (Profile - simon - Cloudflare Community) from the CF team has suggested a curl command to demonstrate that GD is resetting the connection and thereby triggering the 520 error

23:24, Sep 9 TK: My version of this command would be:

23:24, Sep 9 TK: curl -svo /dev/null http://completetheorytest.co.uk --connect-to ::160.153.137.218

23:24, Sep 9 TK: and the result shows:

23:24, Sep 9 TK: C:\Windows\system32>curl -svo /dev/null http://completetheorytest.co.uk --connect-to ::160.153.137.218 * Rebuilt URL to: http://completetheorytest.co.uk/ * Connecting to hostname: 160.153.137.218 * Trying 160.153.137.218… * TCP_NODELAY set * Connected to 160.153.137.218 (160.153.137.218) port 80 (#0) > GET / HTTP/1.1 > Host: completetheorytest.co.uk > User-Agent: curl/7.55.1 > Accept: / > * Recv failure: Connection was reset * Closing connection 0

23:25, Sep 9 GD: I am sorry, we will not be able to check about the coding. However, we can check if there is any issue from our side. May I know the domain name?

23:25, Sep 9 TK: As noted in my previous messages: C:\Windows\system32>curl -svo /dev/null http://completetheorytest.co.uk --connect-to ::160.153.137.218 * Rebuilt URL to: http://completetheorytest.co.uk/ * Connecting to hostname: 160.153.137.218 * Trying 160.153.137.218… * TCP_NODELAY set * Connected to 160.153.137.218 (160.153.137.218) port 80 (#0) > GET / HTTP/1.1 > Host: completetheorytest.co.uk > User-Agent: curl/7.55.1 > Accept: / > * Recv failure: Connection was reset * Closing connection 0

23:26, Sep 9 TK: completetheorytest.co.uk and thestudiosws15.com

23:31, Sep 9 TK: A similar CURL command for thestudiosws15.com is:

23:31, Sep 9 TK: 160.153.137.163

23:31, Sep 9 TK: C:\Windows\system32>curl -svo /dev/null http://thestudiosws15.com --connect-to ::160.153.137.163 * Rebuilt URL to: http://thestudiosws15.com/ * Connecting to hostname: 160.153.137.163 * Trying 160.153.137.163… * TCP_NODELAY set * Connected to 160.153.137.163 (160.153.137.163) port 80 (#0) > GET / HTTP/1.1 > Host: thestudiosws15.com > User-Agent: curl/7.55.1 > Accept: / > * Recv failure: Connection was reset * Closing connection 0

23:31, Sep 9 GD: Thank you, please allow me a few minutes to check the account.

23:37, Sep 9 GD: Thank you for your patience. Did you try to remove the Ip from dns and add it back on cloudflare?

23:38, Sep 9 TK: Do you mean did I try disabling the CF proxy+caching option (so connection was direct to GD) and then restore it? If so, then yes I did and though the issue isn’t apparent when CF isn’t caching it reappears when CF caching (and SSL functionality) is restored.

23:39, Sep 9 GD: Yes, and also please remove the hosting Ip once from the dns and then add it back again.

23:40, Sep 9 TK: Are youasking me to do again what I’ve already done repeatedly over the course of several days, i.e. to disable and then reenable CF caching and SL functionality?

23:40, Sep 9 TK: I’m not sure that you mean by remove the hosting IP from the DNS

23:42, Sep 9 GD: Let me explain it again.

23:43, Sep 9 GD: The Ip for the domain completetheorytest.co.uk is 160.153.137.218. It should be added in dns with cloudflare. If you have already added it, please remove it once and then add it back.

23:43, Sep 9 TK: [PNG] FYI, attached is the DNS for thestudiosws15.com

23:44, Sep 9 TK: That is the IP defined in CF, but because proxy caching is enabled in CF the public IP address for thestudiosws15.com is 104.21.43.129 and 172.67.179.137

23:45, Sep 9 GD: Yes, that is the reason you are getting error on the site.

23:45, Sep 9 TK: If I disable CF caching and proxy functionality then the public IP will change to 160.153.137.163

23:45, Sep 9 TK: What do you mean “that is the reason”

23:46, Sep 9 TK: Are you saying that fundamentally CF caching can’t be used with GD Managed WP

23:46, Sep 9 GD: Proxy caching would be the reason for the error on the site.

23:47, Sep 9 TK: Why

23:49, Sep 9 TK: CF blames GD and GD blames CF. You have mutual customers that are having issues and you (GD) need to resolve this with them (CF) else neither of you are helping your paying customers

23:50, Sep 9 TK: Did you look at Godaddy / Cloudflare 520 error (recent change) and Cloudflare Error 520 for GoDaddy Managed WordPress site - #8 by AppleSlayer

23:51, Sep 9 GD: Let me check it

23:57, Sep 9 GD: Please allow me sometime.

23:57, Sep 9 TK: OK

0:02, Sep 10 GD: Thank you for your patience.

0:08, Sep 10 GD: I am still checking it, I really appreciate your patience.

0:09, Sep 10 TK: OK

0:15, Sep 10 GD: Thank you for being online. As you have done all the possible options to fix it. In that case, you can change the nameservers to Godaddy and it will not give you the error.

0:16, Sep 10 TK: That isn’t a real solution, just a way of avoiding an issue. HOw can we escalate this issue so that someone at GD gets in contact with someone at CF to resolve it properly?

0:20, Sep 10 GD: I completely understand your situation. However, the issue you are getting if you are using cloudflare nameservers. We can only make sure if the hosting Ip is updated in dns with them and we cannot troubleshoot or access the cloudflare. Let me check what can be done here.

0:22, Sep 10 TK: I can change the CF DNS settings so that connections to thestudiosws15.com go directly to GD at 160.153.137.163 and I’m pretty confident that the page will then display without issue (albeit via http and not https), but the “curl -svo /dev/null http://thestudiosws15.com --connect-to ::160.153.137.163” command connects directly to GD already and it shows (sometimes) "Recv failure: Connection was reset2 - why is that and how can it be avoided?

0:27, Sep 10 GD: Are you getting this error after changing the CF dns?

0:31, Sep 10 TK: Yes, I’ve disabled CF caching so thestudiosws15.com now resolves directly to 23.229.249.135 and then I’ve issued another “curl -svo /dev/null http://thestudiosws15.com --connect-to ::160.153.137.163” command (though, as you’ll see, that command includes the IP address to connect to, so doesn’t depend on DNS setting) and the result does (say 25% of the time) include “Recv failure: Connection was reset”

0:35, Sep 10 GD: Okay, I am sorry, we are not aware about the commands that you are using as we are not the developers. This might sound confusing to you but believe me if there was something which could have been done from our end, we would have already done that for you but as you can see that we can only help you in managing the DNS which is in your GD account and the in order to manager your CF firewall you need to check with the CF itself. We will not be able to help with the thing which is provided by someone else and which is managed by someone else.

0:37, Sep 10 TK: I understand, but CF ask for data from GD which isn’t visible to customers. Unless CF personnel talk to GD personnel this issue will remain. You’ll see from Godaddy / Cloudflare 520 error (recent change) that one of your customers has 100 sites hosted by GD which are exhibiting the issue and so this isn’t an isolated issue - it requires escalation and someone at GD to work with someone at CF

0:38, Sep 10 TK: How do we escalate this within the GD support structure

0:40, Sep 10 GD: I am afraid, there is no way to escalate it. However, I can forward this feedback to the higher management and they will look into it.

0:40, Sep 10 TK: OK, will I get any response/feedback from your higher management

0:44, Sep 10 GD: I can share your registered email address and also update the notes on the account.

0:44, Sep 10 TK: Please do

1 Like

For Godaddy 520, if I use curl built with CF Quiche/BoringSSL there’s slightly more info for direct origin curl checks noting a OPENSSL_internal:TLSV1_ALERT_INTERNAL_ERROR error if that helps at all. So I’d also double check if Godaddy origin web server - Apache or Nginx etc are configured with SSL ciphers that Cloudflare can communicate with too https://developers.cloudflare.com/ssl/ssl-tls/cipher-suites

HTTP/1.1

curl-http3 --http1.1 -svo /dev/null https://thestudiosws15.com/ -H "Accept-Encoding: gzip" --connect-to ::160.153.137.163
* Connecting to hostname: 160.153.137.163
*   Trying 160.153.137.163:443...
* Connected to 160.153.137.163 (160.153.137.163) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS alert, internal error (592):
{ [2 bytes data]
* error:10000438:SSL routines:OPENSSL_internal:TLSV1_ALERT_INTERNAL_ERROR
* Closing connection 0

HTTP/2

curl-http3 --http2 -svo /dev/null https://thestudiosws15.com/ -H "Accept-Encoding: gzip" --connect-to ::160.153.137.163
* Connecting to hostname: 160.153.137.163
*   Trying 160.153.137.163:443...
* Connected to 160.153.137.163 (160.153.137.163) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS alert, internal error (592):
{ [2 bytes data]
* error:10000438:SSL routines:OPENSSL_internal:TLSV1_ALERT_INTERNAL_ERROR
* Closing connection 0

This part is telling, the Godaddy server response IN is already getting an internal error and not proceeding any further in the handshake

* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS alert, internal error (592):
{ [2 bytes data]
* error:10000438:SSL routines:OPENSSL_internal:TLSV1_ALERT_INTERNAL_ERROR

FYI, non-HTTPS curl origin check returns HTTP 200 status, so HTTPS isn’t working on Godaddy origin server!

curl-http3 --http2 -skvo /dev/null http://thestudiosws15.com/ -H "Accept-Encoding: gzip" --connect-to ::160.153.137.163 --tlsv1.2
* Connecting to hostname: 160.153.137.163
*   Trying 160.153.137.163:80...
* Connected to 160.153.137.163 (160.153.137.163) port 80 (#0)
> GET / HTTP/1.1
> Host: thestudiosws15.com
> User-Agent: curl/7.79.0-DEV
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAAQCAAAAAAIAAAAA
> Accept-Encoding: gzip
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Age: 61579
< Content-Encoding: gzip
< Content-Length: 5301
< Content-Type: text/html; charset=UTF-8
< Date: Thu, 09 Sep 2021 23:31:52 GMT
< Vary: Accept-Encoding, User-Agent
< X-Backend: local
< X-Cache: cached
< X-Cache-Hit: HIT
< X-Cacheable: YES:Forced
< 
{ [1099 bytes data]
* Connection #0 to host 160.153.137.163 left intact

this is a cloudflare issue which started somewhere in july and till date is not resolved

Cloudflare is unstable from few days and its a disaster with 520 error from cloudflare - #23 by user75214 read here

here are the details of the same issue where most users till date are experiencing the 520 error - Cloudflare is unstable from few days and its a disaster with 520 error from cloudflare - #23 by user75214