Cloudflare on WordPress site is getting 521 web server down error message

Answer these questions to help the Community help you with Security questions.

Have you searched for an answer?
Yes,

Please share your search results url:

Describe the issue you are having:

I configured Cloudflare (free) on a website, it’s been working OK for the past 2 days, and today, I started getting the 521 (Web server down) error message.

The server is working since I was able to connect with the IP address through FTP, and I can see in the VPS dashboard that the server is up and running. Also, after pausing Cloudflare on the site, the site began work morally, but without the CDN, of course.

Currently, everything is working because I’m not using Cloudflare.

How do I know exactly what’s the problem before changing settings? Also, what’s the most likely problem?

I’ve been looking into the Cloudflare recommendations, and I have a few questions. Since the site has an SSL certificate and working correctly, I originally selected the “Full” option. Should I change this to “Flexible” to fix the error?

If the server for some reason, is blocking Cloudflare requests, can I whitelist the Cloudflare ips from .htaccess? I feel more comfortable because I wouldn’t have to run commands in the VPS.

Welcome to the Cloudflare Community. You ask some good questions. Hopefully at least some of my responses are useful.

Never use Flexible. As long as your origin certificate is issued by a public CA (or the Cloudflare Origin CA), you should be using Full (Strict).

I wouldn’t count on it. An .htaccess file can be used to modify Apache webserver configurations, if Apache has been configure to allow that, but it is unlikely (but not impossible) that the Apache webserver configuration would be blocking Cloudflare. That is more likely to occur in your server’s firewall.

Unless you are paying someone to manage it for you, you alone are responsible for the configuration and maintenance of a VPS. If you aren’t comfortable running commands on a server, a VPS might not be the best hosting option for you. You are going need to know how to access the system and read logs and manage configuration files, or have someone who can do that for you. There are some software services that provide abstraction of some those tasks, such as Cloudways and ServerPilot, but they aren’t a complete replacement for server management and troubleshooting skills.

You are going need inspect your side of the connection from the logical edge all the way back to your web server. Depending on the environment, this may be entirely on the VPS, but it could require looking into firewall settings with your VPS provider. For example, Digital Ocean has a platform level firewall that you can configure between your VPS and the internet.

1 Like

Thanks for the response. I can do commands, I just want to minimize human mistakes while the site is running that can take a lot of time to undo whatever it’s been done, affecting the server even more.

Actually, the problem is with a Digital Ocean droplet, I saw the firewall in the dashboard, but I didn’t think was going to work. Are you saying that I can use the settings on Digital Ocean > Networking > Firewalls to whitelist the Cloudflare IPs, and these rules will interact with the server?

The DO firewall sits between the droplet and the internet. Any changes you make there affect traffic at that location. You can think of it like a gate into your neighborhood, where your droplet is your house. If you don’t already have a rule in the DO firewall that is blocking Cloudflare, adding a rule to allow Cloudflare isn’t going to change anything. You will certainly want to review your rules in the DO firewall to make sure you don’t have anything there that could be the problem. Your next step should probably be the firewall logs on the droplet itself.

These two pages may be of use to you as you work through this:

Restoring original visitor IPs

Thanks for the reply. The reason why I asked about using the .htaccess was because that was one of the options suggested by Cloudflare, and I just wanted to make sure.

Quote: “You can explicitly allow these IP addresses with a .htaccess file or by using iptables.”

https://developers.cloudflare.com/fundamentals/get-started/setup/allow-cloudflare-ip-addresses/

You are right about the DO firewall. One of the reasons why I didn’t touch it.

Also, are we sure that the 521 error is most likely because of the firewall? Just want to make extra sure.

Nope. We definitely are not. The 521 error indicates that Cloudflare is not receiving a response from your server. Right now that is all we know. In order to troubleshoot that you need to send traffic through Cloudflare and check all the spots where it could get disrupted. Since the OS firewall is logically between Cloudflare and your webserver application, it makes sense to check it for signs of traffic passing or being rejected before moving on to the check web server itself.

How are you managing the OS firewall? Where are you logging firewall activity? Are you running additional tools that interact with the firewall, such as fail2ban or ufw?

I was looking into the firewall logs in more detail, and I found these. Would you say this is enough to say that the firewall is blocking Cloudflare? I have checked the SRC addresses, and they belong to Cloudflare. In total, I’ve seen more than 200 blocks.
PS: I did edit the MAC and DST IPs to post the logs here.

This is from ufw.

Oct 9 03:13:11 server kernel: [321863.958922] [UFW BLOCK] IN=eth0 OUT= MAC=aa:55 SRC=103.21.125.80 DST=192.241.xxx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=TCP SPT=24217 DPT=443 WINDOW=0 RES=0x00 RST URGP=0

Oct 10 23:04:43 server kernel: [479753.958110] [UFW BLOCK] IN=eth0 OUT= MAC=aa:55 SRC=108.162.221.158 DST=192.241.xxx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=61238 DPT=443 WINDOW=0 RES=0x00 RST URGP=0

Oct 10 23:03:52 server kernel: [479703.575523] [UFW BLOCK] IN=eth0 OUT= MAC=aa:55 SRC=108.162.221.176 DST=192.241.xxx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=52244 DPT=443 WINDOW=0 RES=0x00 RST URGP=0

Oct 10 09:16:25 server kernel: [430057.326473] [UFW BLOCK] IN=eth0 OUT= MAC=aa:55 SRC=162.158.62.132 DST=192.241.xxx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=0 DF PROTO=TCP SPT=64694 DPT=443 WINDOW=0 RES=0x00 RST URGP=0

Oct 10 09:20:12 server kernel: [430283.566827] [UFW BLOCK] IN=eth0 OUT= MAC=aa:55 SRC=162.158.62.224 DST=192.241.xxx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=0 DF PROTO=TCP SPT=13066 DPT=443 WINDOW=0 RES=0x00 RST URGP=0

Oct 10 10:11:24 server kernel: [433355.930680] [UFW BLOCK] IN=eth0 OUT= MAC=aa:55 SRC=162.158.62.24 DST=192.241.xxx.xx LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=53124 DF PROTO=TCP SPT=65446 DPT=8443 WINDOW=64240 RES=0x00 SYN URGP=0

These are some logs from fail2ban:

2022-10-10 09:00:36,485 fail2ban.filter [804]: INFO [wordpress-hard] Found 162.158.62.98 - 2022-10-10 09:00:36
2022-10-10 09:01:37,795 fail2ban.filter [804]: INFO [wordpress-hard] Found 162.158.62.6 - 2022-10-10 09:01:37
2022-10-10 09:10:48,327 fail2ban.filter [804]: INFO [wordpress-hard] Found 162.158.62.116 - 2022-10-10 09:10:48

2022-10-11 01:43:59,172 fail2ban.filter [804]: INFO [wordpress-hard] Found 108.162.221.182 - 2022-10-11 01:43:59

2022-10-11 01:36:52,798 fail2ban.filter [804]: INFO [wordpress-hard] Found 162.158.62.214 - 2022-10-11 01:36:52
2022-10-11 01:37:54,128 fail2ban.filter [804]: INFO [wordpress-hard] Found 162.158.62.224 - 2022-10-11 01:37:54

I’d say its a pretty good indicator :ok_hand: . Consider disabling the bans momentarily and observe whether the issue goes away or not.

1 Like

Judicious use of the two IP related links I shared should help get you sorted.

Placing the Cloudflare IPs in your ufw and fail2ban allow lists will prevent them from getting banned. Once you adjust your logging to restore the visitor IPs, you won’t be adding CF IPs to your jails any longer.

Once you know everything is working through the Cloudflare proxy, you might consider adding Authenticated Origin Pull to only allow requests from Cloudflare.

Thanks for the time and suggestions.
I’ll try the changes this weekend when traffic slowdown, and I’ll share the results.

1 Like

Since I have SSL certificate, I only have to worry about adding the rules for https, correct?

@epic.network
Whitelisting the Cloudflare IPs with UFW and fail2ban didn’t work. After whitelisting the IPS, the UFW kept on blocking IPs from the 162.158.x.x range and 24 hours later I started to get the same behavior as before. These are SOME of the blocked IPs I found:
162.158.62.24
162.158.63.33
162.158.62.224
162.158.62.132

On the other hand, fail2ban ignored all the IPS.

The strange part is after whitelisting the IPs only the 162.158.x.x showed up in the logs for fail2band and UFW.

I don’t know what else to do, I have already contacted DigitalOcean, but they say that the droplets don’t have anything else other than UFW and fail2ban.

Thanks,

I just found out something digging around the apache error logs.
It appears that I have many attempts to access the xmlrpc.php from IPs in the 162.158.x.x. However, in the .htaccess, a long time ago, I have a deny access code to any IP other than those IPs from WordPress JetPack that actually needs this service.
I’m wondering if this is causing trouble, which I don’t understand because that Cloudflare protects the xmlrpc.php by default https://support.cloudflare.com/hc/en-us/articles/218377098-wordpress-jetpack-and-cloudflare. If indeed, it protects the xmlrpc.php, why am I getting access attempts to it?

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