Wordpress blog redirecting instead of showing (but other blog works fine)

[hanuman]

Been scratching my head for a long while, and went around the whole topic a few times -- going to ask for pointer.

I have wordpress blogs hosted on a OpenLiteSpeed+Wordpress docker image. Blog at https://www.spiritualselftransformation.com/blog/ is working; but at https://www.hanumaninstitute.com/blog/ fails and redirects to https://www.hanumaninstitute.com

Here's NGINX config for hanumaninstitute.com

server {
    listen        80;
    listen        [::]:80;
    listen        443 ssl;
    listen        [::]:443 ssl;
    server_name   hanumaninstitute.com;
    return 301 $scheme://www.hanumaninstitute.com$request_uri;

    ssl_certificate /etc/letsencrypt/live/hanumaninstitute.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/hanumaninstitute.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    server_name   www.hanumaninstitute.com;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass         http://127.0.0.1:5006;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }

    location /blog/ {
    proxy_pass         http://127.0.0.1:5080/;
    proxy_set_header   Host $host;
    proxy_set_header   X-Forwarded-Proto $scheme;
    }

    #location /files/ {
    #    return 301 $scheme://www.spiritualselftransformation.com$request_uri;
    #}

    listen 443 ssl; # managed by Certbot
    listen [::]:443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/hanumaninstitute.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/hanumaninstitute.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = www.hanumaninstitute.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen        80;
    listen        [::]:80;
    server_name   www.hanumaninstitute.com;
    return 404; # managed by Certbot
}

To create the blog, I used this script, where ${1} is hanumaninstitute.com

sudo bash bin/domain.sh -A ${1}
sudo bash bin/database.sh -D ${1}
sudo ./bin/appinstall.sh -A wordpress -D ${1}
sudo chown -R admin:admin /var/docker-data/wordpress/sites/${1}

echo ""
echo "Add to /var/docker-data/wordpress/sites/${1}/html/blog/wp-config.php"
echo "define('WP_HOME', 'https://${1}/blog');"
echo "define('WP_SITEURL', 'https://${1}/blog');"
echo "define('WP_CACHE', true);"
echo "\$_SERVER['REQUEST_URI'] = str_replace(\"/wp-admin/\", \"/blog/wp-admin/\",  \$_SERVER['REQUEST_URI']);"

In /var/docker-data/wordpress/sites, I have 'spiritualselftransformation.com' with works, and now 'hanumaninstitute.com'.
each contain "html/blog/wp-config.php" with personalized URL and database

define('WP_HOME', 'https://www.hanumaninstitute.com/blog');
define('WP_SITEURL', 'https://www.hanumaninstitute.com/blog');
$_SERVER['REQUEST_URI'] = str_replace("/wp-admin/", "/blog/wp-admin/",  $_SERVER['REQUEST_URI']);
define('DB_NAME', 'hanumaninstitutecom');

btw the script used to work fine, this time it returns a "insufficient memory" error when creating WordPress app; I instead copied "html" folder from the other blog and updated URLs and database in wp-config.php. Not sure why "sudo ./bin/appinstall.sh -A wordpress -D ${1}" is now failing but shouldn't be an issue here.

I have finally setup a real website at the root, and removed any NGINX redirection.
I have updated the certificate to be valid (as confirmed on the root website).
OpenLiteSpeed is being called because calling www.hanumaninstitute.com/blog/ adds some log entries; but no errors.
Adding "html/blog/test.txt" and trying to access it redirects and fails to find it.
I haven't done any custom OpenLiteSpeed configuration other than running wordpress setup scripts to add domain and files.
I just updated .env with OLS_VERSION=1.8.3 PHP_VERSION=lsphp83

So...
- spiritualselftransformation.com/blog works, but hanumaninstitute.com/blog doesn't.
- NGINX redirection works, because OpenLiteSpeed is logging activity when accessing the page
- There's a valid certificate on the domain so it's not that
- It's not Wordpress because a plain text file fails to work

There's only OpenLiteSpeed left. Via web UI, VHost Templates contains "docker", with
Virtual Host Name: hanumaninstitute.com
Domain Name: hanumaninstitute.com,www.hanumaninstitute.com
Context contains '/' pointing to '$DOC_ROOT/'

This is a pretty complete diagnostic. Got any idea what I'm missing?

This is the test page that should be accessible.
https://www.hanumaninstitute.com/blog/test.txt

 

[Cold-Egg]

OLS + WP should be a complete stack already, not sure why you want to add an additional layer?
From the response header, as Nginx is doing the proxy, it's hard to tell if the redirect is made by Nginx or not. Have you tried to curl the blog domain locally with resolve 127.0.0.1:5006 and see if there's any redirect issue with OpenLiteSpeed?

 

[hanuman]

I use NGINX because OpenLiteSpeed only manages a few Wordpress sub-domains; the server hosts various other websites and services via reverse proxy into docker apps.

Hard to test locally by IP; because what OpenLiteSpeed returns depends entirely on the requested domain. By IP-only, there's no domain context.

 

[Cold-Egg]

I mean, can you do something like `curl --resolve www.hanumaninstitute.com:5006:127.0.0.1 http://www.hanumaninstitute.com/blog/` from the host server?

 

[hanuman]

It gives me "301 Moved Permanently"

 

[hanuman]

AAAHH!!! NGINX blog config pointed to 'http' instead of 'https'; I add 's' and it now goes into a OLS 404 page! That's massive progress!

 

[Cold-Egg]

Glad to know you have found the issue.