• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Issue Nginx caching cause too much redirections

Pascal_Netenvie

Regular Pleskian
Server operating system version
Debian 11.6
Plesk version and microupdate number
18.051u1
Hi,
In 3 days i had 2 down alerts from one of our monitoring system (24x7) on 2 sites on 2 different servers.
Each time alert is there is too much redirections (301 to 302 to 301 etc ) between http and https.
Problems was confirmed by www.redirect-checker.org (19 redirections).
And each time the solution was to clear Nginx cache.

These servers run both Debian 11.6 version and Plesk 18.051u1.
And Nginx cache is set to 512 Mb and 1 day lifetime.
We never had this problem before so i presume it come from last update ...
 
Please check the "Hosting Settings" > "Preferred Domain" and the "Hosting Settings" > "Permanent SEO-safe 301 redirect from HTTP to HTTPS" configuration if it matches what you website expects. There must not be a difference between webserver and website configuration.
 
For Preferred Domain i see where is the webserver setting (in Tools and settings > Server settings) but for HTTP to HTTPS i don't see ...
 
The right place to look is in the subscription, not in the server admin Tools & Settings. Please login to your subscription or open the "Web Hosting Settings" in the subscription.
 
Ok i know and checked this one first.
But in your first answer you say "There must not be a difference between webserver and website configuration".
I don't understand what is webserver part and what is website part.
 
Example: In Hosting Settings of the web server, the web server is configured to redirect all http traffic to https, but in an .htaccess file of the website or the siteurl and home datasets of a Wordpress installation, the URL is given with http instead of https. So the web server will redirect to https, the website opens and realizes it must redirect to http, then the webserver again redirects to https, the website again to http and so on.

For the web server, the settings can be done in the "Hosting settings". For the website content, these can be done anywhere. Typical places are .htaccess and for Wordpress the siteurl and home datasets in the options-table, but for plugins, themes and other CMS there can be different locations.
 
I have checked the 2 websites (it's 2 Prestashop) and there is no redirect in htaccess ...
And in the 2 cases clearing Nginx cache solved the problem.
So it seems it more likely come from NGINX cache ...
 
[...]
And in the 2 cases clearing Nginx cache solved the problem.
So it seems it more likely come from NGINX cache ...

Nginx cache can't be the cause as it only caches content that's already generated upstream. You'll have to search for the source of the redirect issue. Which likely is with your application (Prestashop), because that's what Nginx caches.
 
Last edited:
ISTR there was something about nginx caching pages regardless of protocol, so if a page was first accessed with http, all the links and ressources of the cached page will be wrong when accessed with https, and vice versa ... no idea whether that's still a problem
Having varnish between nginx and apache can also lead to this kind of problem when the site isn't configured accordingly.
 
Strangely the problem was gone for 7 days and it appears again just now.
And like the last time when i empty NGINX cache the problem disappear ...
Why it run ok for one week, then suddenly the problem occurs and it's solved by emptying NGINX cache ??
 
Back
Top