• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Plesk is online but domains are all unreachable

area industries

New Pleskian
Hello.

I'm using Plesk Onyx V 17.8.11

Some day's ago, i've updated some packages on my server by Plesk Update Helper. After that i ran apt-get update via SSH, everything goes right!!!

Now i'm experiencing this error on my server:

My plesk Interface is perfectly running, but all domains are unreachable. If i try to run ping example.com It result correct.

If i restart my Server or Apache all domains return online again. Already follow guides which indicate to change Apache settings etc.

This is proxy_error.log file
Code:
2019/09/04 18:26:44 [error] 3104#0: *78612 access forbidden by rule, client: 5.188.62.5, server: area.industries, request: "GET /?author=12 HTTP/1.1", host: "www.area.industries"
2019/09/04 18:26:44 [error] 3104#0: *78613 access forbidden by rule, client: 5.188.62.5, server: area.industries, request: "GET /?author=11 HTTP/1.1", host: "www.area.industries"
2019/09/04 18:26:44 [error] 3104#0: *78615 access forbidden by rule, client: 5.188.62.5, server: area.industries, request: "GET /?author=12 HTTP/1.1", host: "www.area.industries"
2019/09/05 13:27:03 [error] 3104#0: *143959 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking to upstream, client: 66.249.66.75, server: area.industries, request: "GET /i-segreti-del-marketin$
2019/09/05 13:31:06 [error] 3104#0: *144065 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking to upstream, client: 66.249.66.76, server: area.industries, request: "GET /wp-content/uploads/201$
2019/09/05 13:54:35 [error] 3104#0: *144876 access forbidden by rule, client: 78.85.212.49, server: area.industries, request: "GET //wp-includes/images/wlw/license.php HTTP/1.1", host: "www.area.industries"
2019/09/05 14:42:39 [error] 3104#0: *146321 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.86, server: area.industries, request: "GET /seafield/18540jomx101110623401.htm HTT$
2019/09/05 14:49:23 [error] 3104#0: *146452 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.85, server: area.industries, request: "GET /vanilla-kagu/26465amrggd7404.htm HTTP/$
2019/09/05 15:57:25 [error] 6370#0: *96 connect() failed (111: Connection refused) while connecting to upstream, client: 66.249.66.84, server: area.industries, request: "GET /kagu-1/9835hxglmr1-862.htm HTTP/1.1", upstream: "http://94.2$
 
Some nginx rule or site imcompatibility, causes can be many... an httacess bad rule, some plugin...
 
@area industries

This

If i restart my Server or Apache all domains return online again. Already follow guides which indicate to change Apache settings etc.

is expected behavior, since you are having some issues with Google based IP addresses (66.249.66.***) hammering your Nginx server.

Any reload or restart of Nginx -which also occurs at a reboot of your server- will drop any impeding requests, allowing Nginx to pass requests properly to Apache.

However, you do not provide enough information - the log provided is not sufficient.

Nevertheless, I can make an educated guess about what happens :

a) Nginx is being hammered - this causes a multitude of problems, but it is not the root cause of the problem,

b) Nginx passes a huge number of requests to Apache : Apache cannot handle them all - this is very likely to be a problem related to the root cause of the problem.


I am pretty confident that you have some malicious traffic trying to overload your system or requests that cause an overload of your malconfigured Apache server.


Sure, it is a guess, but you can run a test - just follow the steps below (in chronological order)

1 - install Plesk firewall extension, if you do not have it already - yes, you will need it later to prevent bad traffic reaching Nginx or Apache; for now, it is for testing only

2 - go to "Tools & Settings > Firewall (click)" and activate the firewall

3 - click on "Modify Plesk Firewall rules" and then click on "WWW Server" and a deny rule for the IP range : 66.249.64.0/19

4 - press OK and activate the new firewall ruleset

5 - run the commands :

nginx -t && service nginx reload
service apache2 stop && service apache2 start


6 - open one of the problematic domains in a web browser and verify that the domain is working properly - it should be

7 - go to "Domains > [domain opened in a browser, see step 6] > PHP Settings (click)" and change the parameters

max_execution_time
max_input_time

to contain a value of 120 - this value is often sufficient

8 - click around in the domain opened in the web browser and check your logs that no problems are occurring - it should not be the case

9 - (optional) redo step 7 and increase the parameter

memory_limit

to a higher value - it is often recommended to do so, as long as you do not increase it too much (note : a too high value can cause server-wide issues).

10 - inspect the logs again and verify that no issues are occurring - it should not be the case

11 - (optional) install and activate Fail2Ban to prevent malicious traffic hammering the server


Finally, if you come to the conclusion that nothing odd happens when executing steps 1 to 11, then it must be something related to those Google based IP addresses.

Nevertheless, you can establish the root cause of the problem by removing the firewall ban for the Google based IP addresses - just undo step 3.

If problems reoccur after the Google based IP addresses have been enabled, then that is the root cause of the problem.

If problems do not reoccur after the Google based IP addresses have been enabled, then the route cause of the problem is malicious traffic.

Now you also understand why you did have to activate Fail2Ban and install the Plesk firewall extension : it will enable you to block all undesirable malicious traffic!


Hope the above helps a tiny bit.

Kind regards.........
 
Back
Top