• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Apache & nginx Settings autmaticly deactiv after a while

Kai Kremer

New Pleskian
Hello,

I´ve configured an Additional directives for HTTP as follows:

ProxyRequests Off
ProxyPreserveHost On

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / http://localhost:58080/ connectiontimeout=300 timeout=300
ProxyPassReverse / http://localhost:58080/

This directive works fine so far! If someone calls the url <exampleUrl.de> he see´s the application which is behind the port 58080. The only thing is, that the script just works for a while. After one day or so it is not acitve anymore and I have to "apply" it again.

Can someone tell me how to activate the Additional directives permanently?

thanks in advance,
 
This is the correct place.

How do you realize that the setting becomes inactive? Any error messages? Any specific log entries that could shade some light onto the situation?
 
For today everything works fine. Where can I find error-messages or log-files for that? Are they available directly in Plesk?
 
Error logs of a domain are available in the /logs directory of the subscription or in the GUI "Log" icon. Error logs of your application that is running on the specified port can have any location, depending on what the programmer of the application has developed.
 
Last edited:
I think the nearest explanation for the issue is that a keep-alive configuration is piling up connections to the backend, resulting in an overwhelming number of connections after an undefined time period. This can be a few hours, a day, two days - depending on the number of requests made to the backend. In this scenario the connection will first work perfectly, then at a random time fail and not come backup up unless the web server is restarted, because only a restart will clear the living connections. That restart is done when the web server settings are "applied" as stated in the first post.

I'd next try to disable proxy keep alive with this setting:
SetEnv proxy-nokeepalive 1
(this is an additional directive you need to add after ProxyPass), then see if the issue still exists.
 
Today in the morning the first try to reach the application was not working, same error "ERR_CONNECTION_REFUSED". After some seconds it works! I´ll keep watching.
 
Bad news, it is not working. Today, I get back the error connection refused.

Here the actual conf:

ProxyRequests Off
ProxyPreserveHost On

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / http://localhost:58080/ connectiontimeout=300 timeout=300
SetEnv proxy-nokeepalive 1
ProxyPassReverse / http://localhost:58080/


I´ve added

Index files
Default
Enter custom value: index.jsp (from root-folder of the tomee application)
 
Maybe look at a different place for the reason, e.g in the backend application? What is it doing with the connections? Maybe it is creating something like persistent connections or not shutting down finished processes?
 
Hmm... the error comes only when I try to connect to the domain www.main..... when I connect to the Server directly with the IP-Adress and Port everything works perfect. So there must be something wrong with the nginx or the apache configuration I think.

Do you have another idea?
 
it seems to work. What I have done...
* Add the IP of the server to Whitelist (Fail2Ban of Plesk)
#Plesk -> Tools & Settings -> Security -> IP Address Banning (Fail2Ban) -> Trusted IP Addresses
* Disable the application firewall of the domain
#Plesk Websites & Domains -> Web Application Firewall -> Detection only

Thank you again Peter!
 
For others with the same issue: The above thread was carried through private messages, too, leading to this recommendation:
"Have you checked the fail2ban IP list? You may not have whitelisted two important IPs:
a) 127.0.0.1/8
b) Public IPv4 of the domain
Maybe fail2ban has blocked 127.0.0.1?"

So probably that was indeed the fix.
 
Back
Top