I wouldnât have expected it to conflict, but I wonder if the /etc/nginx/sites-enabled/default Nginx conf is still present and conflicting. It would serve that default Nginx page we see. If it is still there, maybe the Trellis task to remove the default conf didnât complete for some reason. If that file is still there, try running the wordpress-setup role again::
Then visit the http version of the site on a fresh browser to see if the https redirect works.
If that doesnât resolve it, could you tell us what are all the conf files in /etc/nginx/sites-enabled? Maybe there is another file that is conflicting.
Also, I wonder if it might help to see your whole /etc/nginx/sites-enabled/simplynativejapan.com.au.conf file â you might post its contents.
Why the redirect to https?
The https redirect block you posted from your nginx conf is appropriate. However, I donât think it is currently causing the redirect. I believe the redirect is happening because the first successful visit to the https version of the site will set the HSTS header in your browser. From then on, your browser automatically changes an http request to https, so the server will not even see the http request.
Note: You may already know, but you can clear hsts headers to help in testing.
This may or may not be relevant but I know in the past Trellis had some issues with international TLDs; could the version of Trellis that @goodpic is using cause an issue here?
Thank you for your comment @MWDelaney. I am actually using the latest master (HEAD) tree as I needed merge #731 fix. I googled the international TLDs issue and I suppose that has been already fixed in the latest?
I believe roots/trellis#622 (Jul 26, 2016) resolved the international TLD issue, so that shouldnât be an issue given that youâre using latest master, @goodpic.
(Thanks @MWDelaney)
A couple other thoughts came to mind.
You may want to SSH into the server and check for config errors with sudo nginx -t
Also sudo service nginx reload to ensure that Nginx is using your latest config. I could see myself making adjustments till everything looks perfect, wondering why my changes arenât showing up, forgetting that they will not be applied till Nginx is reloaded.
@fullyint Yes, indeed there was a conflict on the nginx conf, and solved by removing it!
The fix
On the production server.
$ cd /etc/nginx/sites-enabled
$ ls
letsencrypt-simplynativejapan.com.au.conf simplynativejapan.com.au.conf
no-default.conf
$ more letsencrypt-simplynativejapan.com.au.conf
server {
listen 80;
server_name simplynativejapan.com.au www.simplynativejapan.com.au;
include acme-challenge-location.conf;
}
$ sudo rm letsencrypt-simplynativejapan.com.au.conf
$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo service nginx reload
Why it happened?
My guess isâŚ
I remember that I had an error when I first provisioned the production server ( ansible-playbook server.yml -e env=production ).
I forgot to set CNAME for the www.simplynativejapan.com.au , and the Letsencrpypt task failed because the API could not reach to the site.
I could complete the provisioning after setting CNAME but maybe the letsencrypt-simplynativejapan.com.au.conf was left during the retry?
Thank you @fullyint for your prompt suggestion. You saved my day!