Hosting server and website problems

In this post I’ll write about website and hosting server problems I’ve encountered over the years – and about (determined) problem causes and solutions. It is planned as a series of “problem – solution”. Will be updated in the following years. Want to keep it all in one place, relatively easy to search. Where it is not of crucial importance, I won’t be noting particular websites, nor hosting providers, or server types – in order to keep the info as brief and easy to navigate as possible.

For problem-solution formating I’ll be using “FAQ” block type, enabled by Yoast SEO plugin (gave up on Yoast in favour of The SEO Framework). Unlike WordPress itself, Yoast’s FAQ creates chema.org compatible blocks (more on this I wrote in the post about WordPress 5 and Gutenberg block editor). Without further ado, let us begin.

Table Of Contents (T.O.C.):
Intorduction – Golden rule

1. “403 Forbidden” error
2. Email delivery problem type a
3. Connection refused PHP error
4. WordPress and another app emails not being sent
5. WordPress sites won’t allow logging in to back-end – PHP!
6. Problem when adding a set of letters to a website
7. WordPress widget editing/updating problem
8. A strange Cloudflare-related problem

1. Golden rule

Always, always check everything on your side.

• Is your Internet connection working (for other websites)?
• Does your computer have any viruses, or other problems?
• Have you paid all the bills?

Then check the hosting provider’s server/network status:

I wrote about this in more detail in the post about technical support.

Only after this is checked, proceed with the other instructions, depending on the problem you are facing, as explained below.

– T.O.C. –

Problem 1 – “403 Forbidden” error

When trying to open a website page, I get:
“403 Forbidden
Access to this resource on the server is denied!”

First thing to check is whether your IP was blocked by hosting provider’s WAF (Web Access Firewall).
This can easily be checked by using a VPN to connect using another IP address (TOR browser can also be used), or using a smartphone and the Internet connection of your mobile network provider (not using your home/work Wi-fi, since then you are likely to get the same IP address as for the computer).
If all works normally then, it means you should unblock your IP address from hosting provider’s control panel. When you log into the control panel and choose the menu similar to the one in the picture below, your IP is usually automatically detected and added. If that’s not the case, use whatismyip.com.

What if connection using another IP is not working too? The following picture gives instructions for the first step:

If your server/network is not on the list, then you must contact the hosting provider’s technical support. When posting a ticket, let them know that you’ve checked the network/server status and have tried using (at least) two different IP addresses to connect, but you still get the same problem.
In this case it’s most probably a problem with the server’s WAF (ModSecurity rules), but could also be something else – they should figure it out.

– T.O.C. –

Problem 2 – Email delivery problem type a

I have several domains (websites) and emails from one of them don’t reach the others

Once a domain is set up on one hosting server, emails sent to it from other domains on the same server will be sent locally (on the same server). Even if you migrate one domain off the server, to another hosting provider, all the emails sent from other domains (websites) on the same (old) server will be delivered only locally.
Even if you delete the domain and/or inbox for a particular email, it could happen that emails sent to it get bounced after attempting to deliver them locally.
For example: bikegremlin.com and io.bikegremlin.com are hosted on server A.
I migrate bikegremlin.com to server B.
Mails sent from [email protected] to [email protected] will not be delivered where they should (they get delivered to server A, while if I delete bikegremlin.com from server A, I get a bounced email error report).
Solution: before migration, set emails to external email service (do this anyway if you are using an external email service, even if you are not migrating the website). Follow the instructions for external email service setup.

– T.O.C. –

Problem 3 – Connection refused PHP error

It’s a good idea to check the contents of the directory where the website is stored on the hosting server (website and error log directory location in cPanel and DirectAdmin control panels). While checking on one server, I saw that error_log file for noting PHP related errors in cPanel is getting filled with the following lines:

[19-May-2020 18:33:14 UTC] Connection refused
[19-May-2020 18:35:15 UTC] Connection refused
[19-May-2020 18:37:16 UTC] Connection refused
[19-May-2020 18:38:15 UTC] Connection refused

A new line is being added every minute, or shorter. OK, something is trying to connect to something and doesn’t manage. This was my troubleshooting procedure:

It was a WordPress website. I have exact copies of the website – two on the same, and one on a different hosting server (the second copy on the same server is used for website and plugin speed and optimization testing – for easy comparison). Such identical website copy is called a staging website. It is handy for testing anything before putting it on the real (“live”, “production”) website.

This made it easy to check whether another, identical website (with the same WordPress theme, plugins and content) on the same server has the same problem, as well as to check whether the problem exists on a different server. I concluded that the problem exists only on the same server, so concluded that the problem is most probably with the hosting server, not with the website/theme/plugins/configuration.

Then I contacted hosting provider’s technical support and, as I was expecting, they said the problem was probably related to some WordPress plugin. Which reminded me of a similar scenario described in the post about hosting provider technical support – called it “Catch 22”. Anyway, tech. support suggested I disable all the plugins and test one by one to see which one causes the problem.

OK, I figured some “digging” on my own is required. So I did just that, trying to figure out which plugin causes the problem and then see if I can give some more useful data to the tech. support. This is by no means a criticism of the technical support. There really were too few information to solve the problem, while tech. support usually has dozens of technical support tickets at a time (see about tickets vs phone technical support).

Activating one plugin at a time, while the others are deactivated, I concluded that LiteSpeed cache plugin is causing problems (why I think LiteSpeed cache is the best is explained in the post about WordPress website caching). To be certain, I tried enabling all the other plugins, except LiteSpeed cache, to see if the problem exists in that case – it didn’t.

I notified the tech. support about that, but it wasn’t enough for them to fix the problem, so I dug into the plugin’s setup/options, trying to find what causes it to keep attempting the unsuccessful connections. I came to the caching menu:

Whoever made that plugin did a great job:

The problem cause is clearly written. Memcached Extension shows “Disabled” (1) because I have disabled that PHP extension on the server, since I’m not using it. But the connection test (2) shows that the chosen, Redis, is failing. Clicking on the link next to that report explains it well – “Learn More“.

After I notified tech. support of that, they reinstalled the Redis service (for which they said they concluded it had stopped working after a recent update) and all was well. 🙂

– T.O.C. –

Problem 4 – WordPress and another app emails not being sent

I aim to keep this “anonymous”, since, in my experience, many problems are “universal”, so don’t intend to unjustly give bad publicity to any particular company. In this case I did note providers and plugins, for a reason: in case there is a particular problem with IP address (range) being blocked, or a particular functionalities being incompatible – this is meant to help technical support pinpoint the problem and (help me) solve it.

a)

I use MXroute mail service. For convenience in sending and reading emails, I connected that email account with Gmail.
And this works with no problems.

b)

I had configured WordPress email sending through SMTP service of MXroute, using Easy WP SMTP plugin, so I don’t rely on the unreliable WordPress mailing functions.
This has stopped working. Noticed the problem on 30th of May 2020.
Error I get when sending a test email:

SMTP ERROR: Failed to connect to server:  (0)SMTP connect() failed. https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting

c)

For WordPress mailing lists, I use Newsletter plugin. It is configured to also use MXroute SMTP (not using any other plugin, nor WordPress mailing functions for sending).
This works.

d)

I use InfiniteWP application (testing it, some reservations, but that’s not the point here) for WordPress website monitoring (with plugin InfiniteWP Client installed on sites that are monitored, through which a WordPress website connects to the application). This application too is installed on a hosting server and configured to use MXroute SMTP service for sending emails.
Email sending through this application has also stopped working.

h1)

One of the hosting providers I use is HostMantis (my review and experience).

h2)

Another hosting provider I’m with is MyW.pt (my review and experience).

Behaviour is the same on several servers and websites (all of the tested), of both of the above noted hosting providers.

e)

For testing, after I had noticed the problem, I installed another plugin for WordPress SMTP mail sending: WP Mail SMTP by WPForms (disabled the previously used SMTP plugin).
This plugin too doesn’t work now.
Error I get when sending a test email:

Could not connect to the SMTP host.

This means your web server was unable to connect to friday.mxlogin.com.

Typically this error is returned for one of the following reasons:

-SMTP settings are incorrect (wrong port, security setting, incorrect host).
-Your web server is blocking the connection.
-Your SMTP host is rejecting the connection.

Recommended next steps:
Triple check your SMTP settings including host address, email, and password, port, and security.
Contact your web hosting provider and ask them to verify your server can connect to friday.mxlogin.com on port 465 using ssl encryption. Additionally, ask them if a firewall or security policy may be preventing the connection - many shared hosts block certain ports.
Note: this is the most common cause of this issue.
Contact your SMTP host to confirm you are using the correct username and password.
Verify with your SMTP host that your account has permissions to send emails using outside connections.

f)

I checked server error logs with both providers – no logged (PHP) errors (error log locations in DirectAdmin and cPanel).

g)

I explained this in a similar way to both HostMantis and MyW.pt technical support, and also posted the info on the MXroute support forum. On that forum, I got feedback from another user, who is also using MyW.pt hosting, but is on another MXroute mail server – it works for them.

h)

I tested with a website that uses hosting provider’s SMPT (not MXroute).
All works properly.

i)

Finally, I tested with a website on the same hosting server, that also uses MXroute, but a different MXroute mail server.
It all works.
However, by the time I tried that, all the other stuff started working again.

My thinking (reasoning) on the potential problem causes:

• Because a) and c) work, on both servers and on all the websites, I suppose MXroute works OK in and of itself.
• Since b) and e) don’t work on either server, and on either website, I suspect something of the stack that both hosting providers could be wrong (CloudLinux, PHP 7.3, LiteSpeed, or something fourth), or some firewall could be blocking MXroute access.
  I tested d) only on h2), it doesn’t work, so I also suspect this problem for that reason.
• It is not impossible, but it’s not very probable that b), d), and e) all stopped working because of the problems (with the plugins and the application) – all at the same time.
• g) and h) lead me to conclude that it could be some firewall blocking one particular MXroute server. Could be wrong – not an expert.
• i) leads me to conclude that there was a problem with MXroute (unless both hosting providers fixed something without letting me know to test if it works). But can’t say for sure. Anyway – it works (for) now. 🙂

I posted this problem on Easy WP SMTP plugin support forum – in case they get any ideas (though I no longer suspect this plugin to be the culprit – as I added there).

I also sent links to this writing to MXroute and hosting providers’ technical support – in case it is of any help/use to them.

It started working again, after a brief hick-up. MXroute suggests this might have caused the problem:
https://forums.cpanel.net/threads/intermediary-ca-certificate-expiration.673165/

– T.O.C. –

Problem 5 – WordPress sites won’t allow logging in to back-end – PHP!

A strange problem. WordPress websites aren’t working, while other websites under the same reseller hosting account are working fine. Usually, this is caused by a plugin conflict – in 99.999% of the cases. However, in this case, disabling all the plugins didn’t help. While cloning or migrating websites to a different server got them running perfectly fine.

Because of this last fact, I had dismissed both Cloudflare and WordPress itself as potential problem causes.

There was a constant load showing exactly 13 entry processes running on every WordPress website. I suspected a Mod Security problem but disabling it didn’t help.

Error logs that I could see didn’t provide an answer.

Finally, the provider’s tech. support figured out that Imunify360 security software update created a problem with PHP 8.0. That’s why non-WordPress websites were running fine – they either didn’t use PHP, or used an older version. While all my WordPress sites are running on PHP 8.0.

– T.O.C. –

Problem 6 – Problem when adding a set of letters to a website

As I was making a tutorial for adding images to a website/forum comment, when I tried adding a link to the “imgbb .com” website, I started getting this error (and the article wouldn’t be saved, updated, nor published):

“Updating failed. The response is not a valid JSON response.”

I tried doing the same on a staging website version with a different hosting provider. There, it went smoothly.

Then I went back to my “problematic” website and opened the Chrome browser’s console to see what goes on there. This error was shown:

“Failed to load resource: the server responded with a status of 403 ()”

OK, the problem is most probably not caused by WordPress, but by the hosting server security.

I decided to open a technical support ticket with my hosting provider (HostMantis). I explained what the problem is and what I’ve tried/determined before contacting them. Pressing the button to submit the ticket… another 403 error – again! On the provider’s support ticket console! 🙂

OK, it’s definitely something on the provider’s end.

Then, I re-wrote the ticket, but I put a space between the “imgbb” and the “.com” part (as I do in this article).

They replied I should disable ModSecurity rules that get triggered when I’m updating an article that contains the “problematic” string and that it’s all fine on their end.

Now, I wouldn’t call myself a top-class Linux server security expert, but I think it’s nonsense to have a security rule prevent entering an ordinary string and/or an ordinary hyperlink.

I don’t want to disable security rules, even temporarily, in order to normally update an ordinary article. This provider has been rock solid since 2019 – stability, uptime, even security, but I still really don’t like this policy and the way they’ve handled this ticket. This was the first time I’ve rated a support request reply with the lowest mark.

I’m waiting on Monday, when someone who knows what they’re doing comes to the office, and maaaaaybe takes a look at my ticket. Even though they’ve closed it – it’s all good as far as they are concerned.

– T.O.C. –

Problem 7 – I can’t edit/update WordPress widgets!

I faced a problem with identical symptoms as problem 6 explained above. This time, when I tried to edit and update WordPress widgets (in the back-end). When trying to save any changes, I got this message:
“There was an error. The response is not a valid JSON response.”

I tried everything: disabling plugins, Cloudflare, ModSecurity, purging cache…

Now, bikegremlin.com websites are using Cloudflare Pro. So, I tried with a staging copy that doesn’t. However, the problem when copy-pasting Google AdSense code in a custom HTML widget persisted even there! Tested with a different hosting provider/server – same!

Then I bothered the hosting provider’s technical support to see if there was anything they could figure out.
To make matters worse, this was top-class technical support, so they really dug into it, and we had reached the point where they asked me for a login account to the site, or a staging copy, to investigate further… no “it’s all fine on our end, bug off” from MDDHosting!

I took a bicycle ride to a store, thinking and clearing my head. Upon return, I tried adding some “ordinary” HTML code to a bikegremlin.com website widget – just a link to a picture. Didn’t work either. Tried the same on a staging copy – it worked! OK, same plugins, theme, and hosting provider. What differs?

The child theme code differs! The production websites have Google AdSense code added to the child theme. I took a look at my browser’s console and saw AdSense code being red (403 errors) when working in the widget back-end. Then I did the stupid thing:

I activated AdGuard AdBlocker!

And that solved the problem. 🙂 It was AdSense all along!

Update – the problem has re-appeared. AdBlocker no longer solves it. The only fix, for now, is a complete removal of AdSense-related code.

Upon further investigating with different clone and staged versions (and different browsers, with no browser extensions installed), it seems like Cloudflare Pro is the culprit after all. It just takes some 15 to 25 minutes upon disabling it and purging caches for the changes to propagate. That’s what skewed my initial troubleshooting attempts. The bottom line is: websites work fine when moved off from Cloudflare (using it only as a DNS, not as a proxy).

When opening the widget editing page in the backend and trying to edit a custom HTML widget, the browser’s console shows this:

I have contacted Cloudflare’s technical support about this problem. Waiting to see if they have any ideas. Cloudflare “Bot fighting mode” has been disabled the entire time.

The support was quick to figure out which firewall rule was blocking this:

Security -> WAF -> Managed rules -> Cloudflare Managed Ruleset -> Cloudflare Specials ->
Service Managed rules
Rule ID 100173
Rule message XSS, HTML Injection – Script Tag

I decided to set the firewall rule to “Challenge” and see if that’s enough or if I must disable it (temporarily) in order to update the widgets:

Not the best UI design – it took about 26 clicks to reach this setting.

“Challenge” didn’t help, so I tried to disable it. That didn’t help either. So, I tried disabling the whole “Cloudflare Specials” set of rules (that’s just one click). Still not working. 🙁

Ralf and Stevewatson301 from LowEndSpirit forum suggested I try editing my hosts file (LES forum link) – to reach my sites directly, avoiding Cloudflare. This doesn’t fly – not with WordPress in a shared hosting environment with a properly configured (and enforced) HTTPS connection.

Solution:
I played some more and found the culprit. In addition to disabling the “Cloudflare Specials” firewall rules, I had to set the OWASP Sensitivity to “Off” – temporarily, in order to update the widgets.

Security -> WAF -> Managed rules -> Package: OWASP ModSecurity Core Rule Set ->
Sensitivity: Off

These changes propagate practically instantly!

MDDHosting & Cloudflare technical support and LowEndSpirit folks were right to suspect Cloudflare firewall from the start. I didn’t see it at first, and later just couldn’t figure out right away which rule exactly is causing the problem.

I’ve updated my Cloudflare Pro and WordPress APO tutorial with this info, in case anyone else runs into similar problems.

– T.O.C. –

Problem 8 – A strange Cloudflare-related problem

HetrixTools is my favourite uptime monitor. This morning, I tried to open a page on my cycling-related website in Serbocroatian, only to find an Error 524. However, HetrixTools was showing my site to be online!?

That site runs the same WordPress themes and plugins as my English cycling website, but it’s not on the same server. I checked: the English site is working without any problems.

OK, I thought that a firewall might be blocking my IP address. So I tried using a VPN (with a UK IP address). When that failed, I tried using a computer at a different location, with a different ISP, just to be more certain sure it was not computer or IP address related.

Since it was still not working, I used the Uptrends tool to check the sites’ availability from a lot of different locations. The English site was working fine, while the Serbocroatian one was not working from London and a few other locations.

I repeated the tests after having disabled the Cloudflare proxy for the Serbocroatian site. What do you know – both sites worked from all the locations! Re-enabling Cloudflare brought the problem back.

It looked as if Cloudflare was blocking the website access from some locations (including the UK and Serbia – which explains why my VPN didn’t help).

I notified my hosting provider, explaining the problem and what I had tried so far. They suggested the problem may be down to WordFence. I disabled WordFence, but the problem persisted (for as long as Cloudflare’s proxy is active).

After a few hours, the hosting provider suggested moving my sites to a different server (from Germany –Hetzner to the UK -OVH).

A strange problem. I find it interesting that HetrixTools didn’t register any downtime – even from their London test location. Will send a link to this text to HetrixTools in case they too find it interesting.

At the time of writing, the problem has been resolved by migrating my accounts to a different, UK-based hosting server.

Update:
The problem had reoccurred on the UK server. This time, we gave it some more “head bashing.” It turns out the culprit was Cloudflare Railgun. The main domain is on a server that supports Railgun, but a subdomain website is on the UK server, which doesn’t. So, disabling the Railgun has solved the problem, without having to disable Cloudflare proxy. 🙂

– T.O.C. –