Starting June 21st, my client's website started having a problem where the browser shows the message, ERR_CONNECTION_RESET for about 1 second before loading the page. The error message is shown on the first visit to the page, but not on refreshes or subsequent page views. The issue can be repeated by visiting the site again about an hour or more after the previous visit.
Sometimes the error message is different. Here are the messages I have received.
Connection reset by peer
Bad file descriptor
I have also experienced the issue when testing with GTMetrix speed test, which is unable to load the page on the first try, but subsequent attempts work as normal.
The http header checking tool at webconfs.com also fails on the first try, but subsequent attempts work. Failed attempts return "(0)" instead of the http headers.
Google Webmaster Tools' Fetch As Googlebot, and PageSpeed Insights also sometimes fail to load pages from the site.
The way it fails to load on the first attempt, but subsequent attempts work - and then it all seems to start over after about an hour - leads me to believe that this has something to do with how pages are being cached. My theory is that the browser tries to load the page from the cache, but no cache is available for the page. The next time, the page is read from the cache. It is as if the user is not being sent to the original page when no cache is available.
I have tested with plugins deactivated, Wordfence security disabled, optimized the mySQL database, and tested on Chrome, Safari and Firefox browsers. The problem was observed most often on Chrome.
While browsing the site's files via sFTP, I noticed that the mu-plugins that are included with Managed Wordpress were updated on June 21st, and suspect the problem may be related since it was not happening before that date.
The website is https://klaxos.com
Solved! Go to Solution.
I have a site hosted on GoDaddy managed WordPress. I am having the same issue for the past 2-3 days. It is exactly the same as what nickker9 has mentioned above.
The err_ssl_version_interference error page comes prior to loading and there is a delay while being redirected to my homepage.
Is it something to do with the hosting?
My website is www.digitug.com
Any help would be highly appreciated.
No solution found. I spent about an hour and a half on live chat and on the phone with GoDaddy support who both said they could not duplicate the problem. I am hoping this is one of those things they first deny and then quietly fix within a few days of it being reported.
Did you call GD support? I tried the chat support, phone support and even Twitter. All claim to have no other reports of the problem except for mine. Meanwhile, my client has several customers and friends who can confirm the issue exists and I have tested it from multiple locations/IP addresses, and different browsers. It happens mostly with the Chrome browser, but I have been able to reproduce the error message with different online tests that crawl the site. Google Webmaster Tools' fetch tool also has a problem with the site.
I am curious if you called, did they claim that nobody else has the problem? I feel like they are gaslighting me.
This is a known issue with how the Chrome browser attempts to establish secure connections with web servers. According to Google, they're using TLS 1.3 for these connections, and the "err_ssl_version_interference" error is presented when something on the server side is buggy in its support for TLS 1.3. The only suggested solutions I've seen are to have people change their preferred TLS method in Chrome (a useless suggestion for public web sites) or to update/replace the network devices/software that's not properly supporting TLS 1.3 (something GoDaddy clients have no access to do).
I'm far from an expert in any of this, but to me it seems Google is surfacing the problem in an annoying way, while the actual issue appears to be with GoDaddy. I'd like to hear a better explanation in lay terms too. I haven't seen GoDaddy address this yet (someone please point to an actual answer if so), but it's a serious issue. Don't let them tell you it's only you or it's not their problem.
i am facing the same issue, and as i checked you website is working fine,
Can you please guide me how to solve this issue
We switched from GoDaddy's Managed Wordpress to normal linux hosting and the problem was solved. This was after several denials of the problem by GoDaddy - even though one of their techs was able to replicate the issue just a few minutes before saying there was no problem.
So for this site, the solution was to stop using GoDadyy's Managed Wordpress.
I'm having the exact same problem. GoDaddy is telling me that it's because I have "mixed content."
they are using https://www.whynopadlock.com to test my site and it says
"The Mixed content tests failed. Please be sure that you can connect to your site over SSL and try again.
Error Returned: net::ERR_CONNECTION_RESET at https://michaeljsilverberg.com"
I've tested other pages, blank pages even and I get the same error, just as Nickker9 detailed in his original post.
My client is frustrated that I can't provide an answer and GoDaddy seems reluctant to help.
What are we supposed to do?
This is DEFINITELY a Godaddy hosting issue.
I have several websites on the same account for multiple clients and a number of them Managed Wordpress. Some sharing the same server IP's and some not.
I also know a friend with another Godaddy account who has a couple of sites hosted with Godaddy Managed Wordpress.
BOTH ACCOUNTS, ALL SITES share the same problems as described. (also tested on an iPhone outside of the LAN and on Edge so it's not a Chrome or LAN issue).
Considering moving all my websites and accounts away from GoDaddy - no other option for it, this will cause a great deal loss of income for Godaddy.
Same issues & similar timeframe for us on our Managed WordPress Hosting site but not our cPanel site. GT Metrix will no longer test our MWH based site with a connection reset by peer error every time for months now.
I just don't have the time to troubleshoot this issue but definitely confirm the ongoing problem exists.
Here is a workaround to a side effect of these error connection & connection reset issues to do with internal WordPress cron jobs.
These error connection and connection reset problem affect the ability of the external cron job service (that I use) to run without throwing an error message, which then causes them to suspend operation.
Until these connection issues are fixed here is a workaround solution for anyone running an external cron job service, how to still make it work with Managed WordPress Hosting.
No Built-In Cron Job with MWH
With Managed WordPress Hosting there is no option to run a cron job like you can with cPanel via so if you want the internal WordPress wp-cron.php function to run on a set timed basis, you have to use an external cron job service.
First off disable the internal wp-cron.php service by modifying the wp-config.php file.
The external cron job service I use is www.setcronjob.com there are many of them out there but this one works well for me. The essential setting you modify is on Failures and Retry.
Check the Test cronjob setting to ignore HTTP status code.
What this does is despite the error connection or connection reset HTTP status code returned, the cron job doesn't disable itself after the failure message. Even though the website connection resets the cron job still activates the wp-cron.php function in Managed WordPress Hosting so the wp-cron queue continues to process jobs.
The basic cron job setup is as follows with your website address in the grayed out box.
To be clear you don't have to use an external cron job service but the advantages are to be able to specify how often the wp-cron.php queue fires, rather than relying on visitor traffic to your website. If you have too few visitors the cron queue doesn't fire often enough and if you have too many visitors the cron queue can fire too often, causing resource stress.
An external cron job service can specify how often the wp-cron queue fires, in my case I've told it every 15 minutes.
This is no solution to the underlying reset issues but a workaround for your external cron jobs if anyone else is having the same problem to keep your website running properly. Hoping this helps.