Improve nginx server block non-www to www

Question

Our current "non-www to www" code at nginx.conf is below. While it seemed to work, now we noticed it's causing errors.

Please don't mark as duplicated. Similar cases are old and seems not to work anymore. Thank you.

When our nginx was created, user typed "example.com" and would be correctly served with "https://www.example.com", so our initial nginx.conf worked. But then Chrome (~2021) adopted default "https" and we didn't noticed that users were receiving a SSL error by being served with "https://example.com" while SSL is generated to "www" domain.

Recently we discovered this and updated nginx.conf as below. We didnt't find a suitable way to change from "https://example.com" to "https://www.example.com" without issuing SSL cert to "example.com".

Recently it was noted on WordPress some slowness to acces some pages, including wp-admin pages. The memory_limit was increased but didn't changed this behavior. Then we noticed issues at "Tools > Site Health": The REST API encountered an error and Your site could not complete a loopback request. We then digged into this and found that while WordPress has "URL = IP" (before published) no issues are shown; when it's changed to "URL = www.example.com" those issues arise.

Seems to me that the root cause is at nginx.conf and we would like some suggestions.

# Moves to HTTPS and serve certbot certificates
server {
        listen          80;
        server_name     example.com www.example.com app.example.com;
        location ~ /.well-known/acme-challenge/ {
                root    /var/www/certbot;
        }
        location / {
                return  301     https://$host$request_uri;
        }
}

# Includes www
server  {
        listen          443 ssl;
        server_name     example.com;
        error_log       /var/log/nginx/example.com.error.log;
        access_log      /var/log/nginx/example.com.access.log;
        ssl_certificate         /etc/letsencrypt/live/example.com/fullchain.pem;
        ssl_certificate_key     /etc/letsencrypt/live/example.com/privkey.pem;
        ssl_dhparam             /etc/letsencrypt/dhparams.pem;
        return          301     https://www.example.com$request_uri;
}

# WordPress site
server  {
        listen          443 ssl;
        server_name     www.example.com;
        error_log       /var/log/nginx/www.example.com.error.log;
        access_log      /var/log/nginx/www.example.com.access.log;
        ssl_certificate         /etc/letsencrypt/live/www.example.com/fullchain.pem;
        ssl_certificate_key     /etc/letsencrypt/live/www.example.com/privkey.pem;
        ssl_dhparam             /etc/letsencrypt/dhparams.pem;
        location ^~ / {
                proxy_pass              http://10.0.0.131:80;
                proxy_set_header        Host                    $host;
                proxy_set_header        X-Real-IP               $remote_addr;
                proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
                proxy_set_header        X-Forwarded-Proto       $scheme;
        }
}

server  {
        listen          443 ssl;
        server_name     app.example.com;
        error_log       /var/log/nginx/app.example.com.error.log;
        access_log      /var/log/nginx/app.example.com.access.log;
        ssl_certificate        /etc/letsencrypt/live/app.example.com/fullchain.pem;
        ssl_certificate_key    /etc/letsencrypt/live/app.example.com/privkey.pem;
        ssl_dhparam            /etc/letsencrypt/dhparams.pem;
        location ^~ / {
                proxy_pass              http://10.0.0.160:80;
                proxy_set_header        Host                    $host;
                proxy_set_header        X-Real-IP               $remote_addr;
                proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
                proxy_set_header        X-Forwarded-Proto       $scheme;
        }
        error_page      400 401 402 403 404 500 502 503 504 =200                /error/unavailable.html;
        location = /error/unavailable.html {
                internal;
                alias /etc/nginx/html/error/;
                try_files /unavailable.html =404;
                access_log      /var/log/nginx/error.log;
        }
}

UPDATE 1:

Error #1:

When testing the REST API, an error was encountered:

REST API Endpoint: https://www.example.com/index.php?rest_route=%2Fwp%2Fv2%2Ftypes%2Fpost&context=edit

REST API Response: (http_request_failed) cURL error 28: Connection timed out after 10000 milliseconds

Error #2:

The loopback request to your site failed, this means features relying on them are not currently working as expected. Error: cURL error 28: connection timed out after 10001 milliseconds (http_request_failed)

UPDATE 2:

Layout: there is a proxmox server (10.0.0.3) behind a firewall appliance (10.0.0.1). At proxmox there are 2 containers: nginx (10.0.0.125) and wordpress (10.0.0.131). The "app server" (10.0.0.160) runs at another machine.

Firewall: disabled at proxmox ("pve-firewall stop" at cluster level); disabled ufw at containers; disabled "wordfence" at wordpress.

Regarding "connection refused", the firewall appliance log doesn't show any block. I guess that since this was an attempt to connect between two devices under the same interface, in this case the firewall appliance doesn't interfere. At "wordfence" within container, I saw no records with "wp-json" (which is part of the http request).

nginx container (10.0.0.125) "/etc/hostname": nginx

nginx container (10.0.0.125) "/etc/hosts":

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
# --- BEGIN PVE ---
10.0.0.125 nginx.local nginx
# --- END PVE ---

wordpress container (10.0.0.131) "/etc/hostname": example

wordpress container (10.0.0.131) "/etc/hosts":

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
# --- BEGIN PVE ---
10.0.0.131 example.com example
# --- END PVE ---

Ping: both nginx and wordpress container can ping proxmox (10.0.0.3), firewall interface (10.0.0.1), google.com, and each other.

Answer 1

I'm a bit confused by your question, but....

return 301 https://$host$request_uri;

This is a bit silly. $host resolves to the FIRST entry in the list of values given to server_name. So it will redirect to example.com

without issuing SSL cert to "example.com".

So? Its not costing you anything. But why do you have 2 separate certificates instead of just using one with both domains on it? (BTW this is not going to fix your "slowness" issue - it's just good housekeeping).

WordPress some slowness

Just some? Or do you mean "more" slowness? Wordpress performance is an oxymoron.

while WordPress has "URL = IP" (before published)

Perhaps this is some inner working of Wordpress - I am struggling to derive much meaning from your description. Find the URLs that are being accessed and try them out for yourself FROM THE SERVER HOST. Check the corresponding log entries. If that doesn't answer your question then try asking here with the URLs which are causing the issues and example log entries.

Answer 2

Do you have/can you get a SSL certificate that serves both www.example.com and example.com? Getting rid of this potential source of problems would probably ease the other issue(s)...

MODIFIED SEQUENCE OF STAGES OK. So the next stage is to pull the drains up in nginx.conf and test for traffic propagation.

1. Check using curl or wget from machine A outside the firewall that you can reach the proxmox machine. I'd suggest configuring nginx on the proxmox machine itself - i.e. 10.0.0.3

Just use a simple nginx.conf that displays a static page.

2. Then from the same machine A check you can reach nginx in a container on the proxmox machine. So the simple nginx.config is running on 10.0.0.125 - and a port is exposed on the proxmox machine that will reroute to 10.0.0.125:80

3. Once this happens try putting the multiple DNS listens (www.example.com, app.example.com etc. ) into the nginx in the container. Check this works with port 80 and then with SSL on 443...

Now go to what had been my step 2 earlier.

4. Try putting spoof HTTP return codes deliberately into the location blocks... This is an easy way to discover what the nginx.conf is actually doing.

server_name: www.example.com
...
location ^~ / {
return 401 "Reached location block 1"
proxy_pass http://10.0.0.1:80;
...
}

server_name: app.example.com
...
location ^~ / {
return 402 "Reached location block 2"
proxy_pass http://10.0.0.111:80;
...
}

Let us know what you get.. Please post any entries in the error or access logs..