I've moved (manually, db backup + folder transfer) 4 wordpress websites from one host to another, maintaining the same configuration (nginx proxy manager in docker on 80/443 plus apache on 444/https). The ssl terminates on nginx (letsencrypt).

The apache configuration is the same (virtual hosts configuration has been simply copied).

3 of the 4 work, 1 goes into a redirect loop (no trailing slash found in any configuration).

EDIT: what would help in the investigation? I've tried disabling the plugins (changing plugin's folder name), disabling the .htaccess file (to get at least access to wp-admin) changing site name/url in the db /served names in apache / A/Cname config in provider dns config with every possible combination to understand what fires the 301 redirects with no effects.

Actually, the apache logs do "move" so the request arrives to nginx proxy manager and then is redirected as it should to apache, but then the redirection happens and something goes wrong.

Any hint about what to investigate?

  • What URLs does this redirect loop include? Mar 2, 2023 at 18:06
  • the first 2 ids of the table wp_options has https://example.com set as both site url and home (no trailing slashes and nothing weird in it). I've tried serving alternatively example.com and www.example.com both in nginx and apache with all the possible combination. no results. the redirection loop includes what nginx receives, so if it receives www.example.com the loop goes with that, otherwise with example.com Mar 2, 2023 at 18:29
  • So its redirecting back and forth between https://example.com and https://www.example.com? Or are you saying it a self redirect for either of those two URLs? Mar 2, 2023 at 19:34
  • Can you use curl to test like curl --head https://example.com and edit the results of that into your question? Same for any other URLs that are redirecting badly. Mar 2, 2023 at 19:35
  • 1
    @NikRubblers Please add your solution as an answer and select it as the answer when you can - thanks.
    – dan
    Mar 3, 2023 at 18:27

1 Answer 1



I added nginx proxy manager after configuring apache to serve directly the websites. Reading about the best practices on how to correctly serve wordpress behind nginx and apache, I came to the solution to terminate the ssl on nginx but still leaving apache on the ssl configuration (this avoided me to set headers such as x-forwarded-proto and others on nginx and modify wordpress configuration).

The three working wordpress instancess still had the letsencrypt configuration pointing to the (unused, expired) old certificates.

the last (not working) one instead hadn't. Adding the three missing lines enabling letsencrypt ssl configuration and the not anymore used (actually expired and wrong) certificates on the apache vhost configuration file prevents the redirection behaviour.

That's sort of weird: if I am supposed to serve apache on the https side terminating the ssl on nginx, why should apache be cofigured with its own (even fake) certificates? If I only enable ssl engine on apache without specifying the certificates' path, on reloading I get an error.

So I'm actually terminating the ssl on nginx, and let apache think he has his own certificates that he will never use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.