Christopher Neuman

Thanks for the additional information. At this point, I would start looking at recovery options rather than continuing to chase down the original hosting provider.

A couple of questions:

1. Do you control the domain name? Specifically, do you have access to the domain registrar and the ability to update the nameservers or DNS records?
2. Do you have a backup of the website? This could be a WordPress backup, a backup from the previous developer, or even a copy of the website files and database.

If you control the domain, you have options even without access to the original hosting account.

Here’s how I would approach it:

1. Set up a new hosting account under your organization’s control.
2. Restore the website from a backup, if one is available. Make sure you have both the WordPress files and database.
3. If no backup exists, I would start rebuilding the website using whatever content and images you can recover. The Wayback Machine at archive.org may have historical snapshots of your website that you can use as a reference.
4. Once the website is ready, update the domain’s A record or nameservers to point to the new hosting environment.

One important consideration: Since your email is hosted separately through HostGator, be careful when changing nameservers. You’ll need to preserve your existing MX, SPF, DKIM, and other email-related DNS records to avoid disrupting email delivery.

Personally, I would keep the existing nameservers in place if you have access to manage the DNS records and simply update the website’s A record when the replacement site is ready.

The important thing now is determining whether you control the domain and whether a usable backup exists. If you have both, recovery should be relatively straightforward. If you only control the domain, rebuilding may be your quickest path forward.

@kcaluwae Based on what you found, I really don’t think this is a Gutenberg or WordPress problem.

The biggest clue is everything works when you turn off the Cloudflare proxy, but you start getting the 522 errors again as soon as Cloudflare is enabled. Since you’re also seeing the same thing on two sites on the same Hetzner server, I would focus on Cloudflare and the connection between Cloudflare and your server.

I would first check your Cloudflare settings. If you have WAF rules, rate limiting, Bot Fight Mode, Rocket Loader, or any custom Cache Rules enabled, try temporarily disabling them one at a time and see if the problem goes away.

I would also check your DNS records in Cloudflare. If you have an AAAA record, make sure IPv6 is actually configured and working correctly on the server.

Since this is a 522, I would also check the server itself to make sure something isn’t blocking or rate limiting Cloudflare. This could be the Hetzner firewall or something on the server such as CSF, Fail2Ban, firewalld, iptables/nftables, ModSecurity, or another security system.

One thing that could really help narrow this down is watching your server access/error logs while you reproduce the problem. When one of those JavaScript files gets a 522, check if the request actually shows up in your web server access log.

If the request never reaches the web server, then I would suspect something is blocking or timing out the connection between Cloudflare and the server.

Since everything works perfectly when you bypass Cloudflare, I wouldn’t spend much more time changing WordPress, Gutenberg, PHP, or plugins. I would focus on figuring out what is happening between Cloudflare and the Hetzner server.

The first thing I would do is temporarily disable the Cloudflare proxy for the domain (turn the orange cloud gray) and test the site again. Since you mentioned Gutenberg works when Cloudflare is bypassed, that should help confirm the problem is between Cloudflare and your hosting server.

A 522 generally means Cloudflare is having trouble connecting to the origin server.

I would also check with your hosting provider to make sure the server isn’t experiencing an outage, high load, networking problems, or other issues. Since you’re seeing the same problem on two WordPress sites hosted on the same server, that makes me suspect the server or its firewall/security configuration before an individual WordPress plugin.

While reproducing the problem, check your website/server error logs. If you’re using cPanel, Plesk, or DirectAdmin, you should be able to view these from your hosting control panel.

I would also check whether Wordfence or a server-level firewall/security system is blocking or rate-limiting Cloudflare IP addresses.

Once you find and correct the underlying issue, turn the Cloudflare proxy back on and test again.

Since both sites on the same server are affected and they work when Cloudflare is bypassed, I wouldn’t focus on the caching plugin first. I’d start with the host/server, firewall, and the connection between Cloudflare and the origin.