Duplicated version of a local (WordPress) site isn't available online in an Nginx environment

Question

In my Ubuntu 16.04 Nginx environment I tried to create an online test version of a local WordPress site. The original site works fine and is accessed in HTTPS (the lock favicon is green in all pages).

My current state and problem

When I browse into my_ip_addrres/test I land on a 404 page in the original site (the local site I desire to duplicate), even though the URL remains my_ip_addrres/test. Moreover, all main menu links in that 404 page with my_ip_addrres/test URL point to the original site.

My desired end state

When I'll navigate to my_ip_addrres/test in whatever browser, I'll land on the duplicated version of the original site, and will operate it just as I would operate the original site, so I could go to my_ip_addrres/test/wp-admin, log in, and change that test site.

What I did so far to duplicate the original site

I basically did everything with the following bash commands. Please use these if you wish to reproduce in your end:

cd /var/www/html/
read domain # Domain of the site for duplication.
read -s rps # Password for Mysql root user.
read -s sps # Password for Mysql DB user.

cp -r ./${domain} ./test/
sed -i "s/${domain}/test"/g ./test/wp-config.php
cp -r /etc/nginx/sites-available/${domain}.conf /etc/nginx/sites-available/test.conf
sed -i "s/${domain}/test"/g /etc/nginx/sites-available/test.conf
ln -s /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled/test.conf

echo "CREATE USER 'test'@'localhost' IDENTIFIED BY \"${sps}\";" | mysql -u root -p"${rps}"
echo "CREATE database test;" | mysql -u root -p"${rps}"
echo "GRANT ALL PRIVILEGES ON test.* TO test@localhost;" | mysql -u root -p"${rps}"

mysqldump -u root -p"${rps}" "${domain}" > test.sql
mysql -u test -p"${sps}" test < ./test.sql

cd test 
wp search-replace "${domain}" "MY_IP_ADDRESS/test" --allow-root

Further details

1) I had about 1300 replacements in the database after running the above WP-CLI search and replace command.

2) /var/www/html/test/wp-config.php:

define('DB_NAME', 'test');
define('DB_USER', 'test');

Nginx confs

• /etc/nginx/nginx.conf
• Original site's conf (domain omitted)
• /etc/nginx/sites-available/test.conf (I've changed it manually and then restarted the server)

Logs:

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

tail /var/log/nginx/error.log
tail /var/log/nginx/access.log

• Both tails show no errors regarding /var/www/html/test/.

My question

What remains a possible cause for the test site not to go up from my_ip_addrres/test? As an Nginx newbie, I really feel I tried everything in the arsenal...

Answer 1

I really don't need anything beyond accessing it directly from the IP

Options:

1. Just save yourself a headache and a half and use a test.example.com domain name. You don't even have to publish valid DNS records just edit your local HOSTS file. And add a server name directive to the test.conf file.
2. You need to ensure that the test config is the FIRST config that is loaded. Change the file name in sites-enabled to 000-test.confThis means anyone doing anything silly will see your test site.
3. Add a server name directive to the test.conf with the server IP
4. Manually include the individual config files in order rather than the entire sites-enabled

Explanation

Place a HelloWorld.html file in /var/www/html/example.com/test/. Browse to IP_ADDRESS/test/HelloWorld.html and you will see the contents of your file. Since your configs have no server { ... } with a servername that corresponds to http://YOUR_IP/ it uses the first server { ... } block as default. Statistically speaking example.com.conf is loaded before test.conf

Nginx Is looking int he wrong root for your file because the main website is the default.

Recommendation

Use option 1 or 3. Your live site should probably be the default website visitors see. I would opt for option 1 because it lets your further "hide" your test site. Option 3 will make "http://ip/test" but for reasons above I still prefer option 1.