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.
Intorduction – Golden rule
- “403 Forbidden” error
- Email delivery problem type a
- Connection refused PHP error
- WordPress and another app emails not being sent
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.
Problem 1 – “403 Forbidden” error
When trying to open a website page, I get:
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.
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.
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. 🙂
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.
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
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.
One of the hosting providers I use is HostMantis (my review and experience).
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.
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.
I checked server error logs with both providers – no logged (PHP) errors (error log locations in DirectAdmin and cPanel).
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.
I tested with a website that uses hosting provider’s SMPT (not MXroute).
All works properly.
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: