Unable to get this working behind Nginx reverse proxy

Hey, I run a Proxmox VE with lxcs for my various services and now wanted to spin up a Wordpress on a new lxc. Love the idea of Turnkey Linux so decided to give it a go.

All services exposed to wan are behind å Nginx reverse proxy (running on its own lxc) and my router is setup to forward all incoming requests for subdomains (confed in DNS on domain) to that so that I need not worry about ports and such. Using Nginx proxy manager since I’ve had no time to properly learn Nginx reverse proxy properly, and besides it gives me such simple way of putting letsencrypt certs on top of whatever service no matter it’s own solution.

but I gave not been able to properly setup Nginx reverse proxy to my turnkey Wordpress lxc. Not even without ssl.

is this a Wordpress issue, or a turnkey issue? Any help on how to get this working is much appreciated 🙏

I tried setting up an Nginx container proxy about a year ago and eventually gave up after getting myself horribly confused. I don't remember figuring out what caused the problem. I guess if I had done then I might have found a fix.

I installed HAProxy instead. It's on the Proxmox host rather than in a container, so not really optimum, but it works fine.

Hi @pivot69, thanks for reporting your issue.

[@packman2008 - thanks for your input too. Out of interest, were you also using "Nginx proxy manager" or did you manually configure your reverse proxy (before moving to HAProxy)? If there are any other specifics you can recall on your failed attempts (e.g. what software, etc) then that might also be useful for me.]

I have zero experience with "Nginx proxy manager". But assuming that it is correctly configuring the reverse proxy, then I would expect it to "just work". The Apache config that we ship with is pretty vanilla and I would have expected WordPress to handle being behind a reverse proxy fine.

So without looking, my first guess would be a bug in the Nginx config that "Nginx proxy manager" generates - perhaps it's stripping and/or not providing an HTTP header that WordPress requires? Lots of things will (at least appear to) work fine behind a fairly simple reverse proxy config, but some apps require specific headers for functionality (e.g. lots of modern web apps use headers for security purposes - I suspect that WordPress does that too).

Having said that, after a closer look at our WordPress buildcode I can see that we're configuring WordPress to dynamically set WP_SITEURL and WP_HOME (to HTTP_HOST), so if the reverse proxy isn't forwarding/setting the HTTP_HOST header appropriately (which a reverse proxy generally should), then that could certainly cause issues!

Also a quick google bought up a thread on WordPress support forums. It's specifically referring to use of Apache as a reverse proxy, but the theory should be the same. I.e. try adding this to your WordPress wp-config.php:

if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
        $_SERVER['HTTPS'] = 'on';
}

Note that in theory, that should only be an issue if the reverse proxy isn't providing the HTTPS header. Although I note that the last post in that thread suggests configuring the above in wp-config.php anyway. So perhaps that's not uncommon?

Hopefully those hints get you going in the right direction?!

If not, please provide some more info about the specific issue(s) you're hitting. E.g. what (if any) error message you get when accessing via browser (my guess is a 504 but it'd be good to be sure). Also error messages from both Nginx (in your "Nginx proxy manager" container) and Apache (in your WordPress container) would likely give us more clues about where this is failing. It would also be useful to know if you've made any changes to the WordPress container Apache config. Also a copy of the Nginx config generated by "Nginx proxy manager" would also be incredibly useful.

Regardless of whether you work it out or not, I'd love to hear how you go. If you do work it out, please do post your solution. If you continue to struggle, then please ensure that you post the requested info noted above. Armed with that info, I should be able to reproduce the issue locally. If I can reproduce the bug, then I'm confident that I can develop a workaround, if not a proper fix. If it seems like ti might add value, and not cause issues under alternate config, we may consider including that PHP code snippet above by default.

FWIW, as something of an aside, TurnKey ships with a Let's Encrypt integration built-in. We use Dehydrated rather than certbot as it's much smaller and leaks less info. It works well in my experience, even behind a proxy. Having said that, I have only tested it with a manually configured Nginx transparent reverse proxy (that just transparently passed the TCP traffic to the back end server - without terminating the TLS connection) so YMMV. In retrospect, I probably should have documented my Nginx revers proxy config. Regardless, so long as your reverse proxy transparently forwards all traffic on ports 80 & 443, then getting certs should work fine behind a reverse proxy. I do also get though that configuring all TLS certs in a single host is convenient though, so this is more an FYI rather than a recommendation.

@JedMeister It was about a year ago so at my age memories are hazy ;-) I'd not heard of Nginx Proxy Manager until this thread so I'm pretty sure I was just using a TKL Nginx container and manually configuring it. I don't recall much beyond that, other than going round and round in circles trying to get it working. I would say that my problem wasn't a bug in TKL. It was almost certainly my lack of knowledge/experience with Proxmox and Nginx. I'd not been using Proxmox for long at that time and I've rarely used Nginx favouring Apache for most of my web servers. If I remember more I'll add a note.

Thanks @packman2008. NO worries. Thanks for your input regardless.

Also, in future, please don't hesitate to ask if you hit similar issues with TurnKey (even if you don't think it's specifically a TurnKey issue). FYI most of what I know about Linux I learned helping other people solve their problems.

That has the benefit of not only allowing us to assist you to achieve your goals, but also assists us to understand what pain points our users have. Understanding of pain points can give us ideas for improvements for existing appliances and/or ideas for new appliances.

Hi @pivot69, thanks for reporting your issue.

[@packman2008 - thanks for your input too. Out of interest, were you also using "Nginx proxy manager" or did you manually configure your reverse proxy (before moving to HAProxy)? If there are any other specifics you can recall on your failed attempts (e.g. what software, etc) then that might also be useful for me.]

I have zero experience with "Nginx proxy manager". But assuming that it is correctly configuring the reverse proxy, then I would expect it to "just work". The Apache config that we ship with is pretty vanilla and I would have expected WordPress to handle being behind a reverse proxy fine.

So without looking, my first guess would be a bug in the Nginx config that "Nginx proxy manager" generates - perhaps it's stripping and/or not providing an HTTP header that WordPress requires? Lots of things will (at least appear to) work fine behind a fairly simple reverse proxy config, but some apps require specific headers for functionality (e.g. lots of modern web apps use headers for security purposes - I suspect that WordPress does that too).

Having said that, after a closer look at our WordPress buildcode I can see that we're configuring WordPress to dynamically set WP_SITEURL and WP_HOME (to HTTP_HOST), so if the reverse proxy isn't forwarding/setting the HTTP_HOST header appropriately (which a reverse proxy generally should), then that could certainly cause issues!

Also a quick google bought up a thread on WordPress support forums. It's specifically referring to use of Apache as a reverse proxy, but the theory should be the same. I.e. try adding this to your WordPress wp-config.php:
if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
        $_SERVER['HTTPS'] = 'on';
}
Note that in theory, that should only be an issue if the reverse proxy isn't providing the HTTPS header. Although I note that the last post in that thread suggests configuring the above in wp-config.php anyway. So perhaps that's not uncommon?

Hopefully those hints get you going in the right direction?!

If not, please provide some more info about the specific issue(s) you're hitting. E.g. what (if any) error message you get when accessing via browser (my guess is a 504 but it'd be good to be sure). Also error messages from both Nginx (in your "Nginx proxy manager" container) and Apache (in your WordPress container) would likely give us more clues about where this is failing. It would also be useful to know if you've made any changes to the WordPress container Apache config. Also a copy of the Nginx config generated by "Nginx proxy manager" would also be incredibly useful.

Regardless of whether you work it out or not, I'd love to hear how you go. If you do work it out, please do post your solution. If you continue to struggle, then please ensure that you post the requested info noted above. Armed with that info, I should be able to reproduce the issue locally. If I can reproduce the bug, then I'm confident that I can develop a workaround, if not a proper fix. If it seems like ti might add value, and not cause issues under alternate config, we may consider including that PHP code snippet above by default.

FWIW, as something of an aside, TurnKey ships with a Let's Encrypt integration built-in. We use Dehydrated rather than certbot as it's much smaller and leaks less info. It works well in my experience, even behind a proxy. Having said that, I have only tested it with a manually configured Nginx transparent reverse proxy (that just transparently passed the TCP traffic to the back end server - without terminating the TLS connection) so YMMV. In retrospect, I probably should have documented my Nginx revers proxy config. Regardless, so long as your reverse proxy transparently forwards all traffic on ports 80 & 443, then getting certs should work fine behind a reverse proxy. I do also get though that configuring all TLS certs in a single host is convenient though, so this is more an FYI rather than a recommendation.

Thank you so much for your dedicated reply and support!

I finally got it working, plainly by trial and error going back and forth with Nginx Proxy Manager, various wp-config.php settings and the confconsole. When I finally got it working I felt a bit unsure about what actually was the cause.

First and foremost it was probably an overlaying issue of browser/site cache, and NPM's Letsencrypt certificate function coming in conflict with Turnkey solution (both the self-signed, and the Letsencrypt). I noticed that it would be quite random what certificate it tried serving me...

Anyways, here's the settings needed in NPM:

And the wp-config settings:

define('FORCE_SSL_ADMIN', true);

define('.COOKIE_DOMAIN.', 'media.obfuscateddomain.no');
define('.SITECOOKIEPATH.', '.');

if(isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
        $list = explode(',',$_SERVER['HTTP_X_FORWARDED_FOR']);
        $_SERVER['REMOTE_ADDR'] = $list[0];
  }                                                                                                                                                                        
define( 'WP_HOME', 'https://media.obfuscateddomain.no/' );
define( 'WP_SITEURL', 'https://media.obfuscateddomain.no/' );
$_SERVER['HTTP_HOST'] = 'media.obfuscateddomain.no';
$_SERVER['REMOTE_ADDR'] = 'https://media.obfuscateddomain.no/';
$_SERVER[ 'SERVER_ADDR' ] = 'media.obfuscateddomain.no';

if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
       $_SERVER['HTTPS']='on';

Of course, this comes in addition to the stuff before ($tableprefix = 'wp';) and after "That's all, stop editing! Happy publishing"

As for the confconsole I only used that for the creation of a Letsencrypt cert. However, to get this working I needed to get everything working without ssl (port 80) and without the self-signed cert on port 443 first. This is because Letsencrypt wouldn't let me have a new cert without this first.

So, my initial setup before acquiring the Letsencrypt cert was like this:

In NMP I had to use Scheme: http and Forward Port: 80 Same with the "Custom locations" tab, and in the extra settings I had proxy_set_header X-Forwarded-Proto http; In the SSL tab I used None for SSL certificate

In the wp-config I am a little bit unsure of what was the actual config when I got it working un-encrypted, but I'm fairly certain that everything referring to "https" was replaced with "http"

Then, finally to get a Letsencrypt certificate installed in the turnkey lxc I logged in through the webshell (promos console did not work in the same way as webshell for some reason) and then to confconsole to get my certificate. Of course I also made sure it would auto-renew.

As soon as this all was working I had it changed back into the current settings referred to above.

Hope this can be of any help to others in the same situation. I am super-happy to finally have a local Wordpress install on a Proxmox lxc so that I can utilise my tens of terabytes of zfs storage instead of being stuck to a webhosters offering of a few tens of gigabytes 😅

UPDATE: Actually, it's still randomly serving me either NPM's Letsencrypt cert or Turnkey's self-signed cert, even now when I have a Letsencrypt cert acquired directly in confconsole and got it confirmed working (by using the IP so that it connects directly to the turnkey lxc and not through the reverse proxy), so I'm not really sure how to fix that finally issue. I tried using the "Force SSL" in NPM to see if that matters but situation is still the same. See attached screenshot for an example of how Zapier complains about a self-signed certificate...

How do I positively remove the self-signed certificate?

@pivot69 Please paste nginx.conf file and sites-enabled/yourwebsite.conf files from nginx it looks like a miss configuration in nginx

I ended up using the turnkey nginx-php-fastcgi instead and that worked much better. Had to do some minor tweaks with the wp-config, and I removed most of what was confed in NPM and its been working great ever since :-D

Ok, so please if possible close the Issue.

Altought i really recomend using nginx for server proxy in general for proxmox if you have questions t.me/inavigator or whatsapp +55 11 97661534

bye

Em sex., 2 de dez. de 2022 às 16:35, Dag Ove @.***> escreveu:

I ended up using the turnkey nginx-php-fastcgi instead and that worked much better. Had to do some minor tweaks with the wp-config, and I removed most of what was confed in NPM and its been working great ever since :-D

— Reply to this email directly, view it on GitHub https://github.com/turnkeylinux/tracker/issues/1762#issuecomment-1335723624, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEVVIFCGAKM6KWL5ED5KYTWLJFRJANCNFSM6AAAAAARCCEGEI . You are receiving this because you commented.Message ID: @.***>

For sure, nginx is great for proxy and in this case it was also best for serving wordpress to a nginx reverse proxy (in another lxc).

Thanks, I will close the issue now.

turnkeylinux / tracker

Unable to get this working behind Nginx reverse proxy #1762