Well, after some thought it becomes clear what goes wrong here:
The server itself resolves its own hostname to 127.0.0.1.
Connections from the outside use CloudFlare CDN (which
uses the public IP address of the server, and not 127.0.0.1).
Try this command:
curl https://alliancechemical.com/satispress/packages.json --resolve alliancechemical.com:443:172.67.74.116
This forces curl to resolve the hostname to the public IP address.
So it’s resolving the production server alliancechemical.com to 127.0.1.1? Isn’t that the IP address of the local host?
Yes, but the server/HTTPS configuration can be completely different or incorrect for connections to 127.0.0.1.
Check out the command above that forces the usage of the public IP address, does that work?
OMFG that worked lol
The web server has the hostname
alliancechemical.com, so it will resolve to127.0.0.1(default IPv4localhost).
This is my production server, right?
And the server is misconfigured (or simply not configured at all) for
127.0.0.1(notably HTTPS connections).
What is misconfigured the production server or the staging server?
Yes, the server itself resolves to 127.0.0.1 instead to public IPv4 address (/etc/hosts default mapping has highest priority).
It may be tempting to change the hostname or host-IP address mapping of that staging server,
but this can cause other issues.
A working local-to-local connection is necessary for WordPress loopback.
Edit: The nginx HTTPS config appears to be somehow responsible for this.
Can you disable CloudFlare temporarily in front of the staging server and then see what TLS/SSL issues may have been masked by it? Then turn it back on, and localhost connections should also work.
I turned off cloudflare proxy in front of staging server.
When you now connect to the public IP address of the web server directly, does that work,
notably from the outside, not from within the web server system itself?
When you now connect to the public IP address of the web server directly, does that work,
notably from the outside , not from within the web server system itself?
You mean just accessing the URL through its IPV4 address
No, on the staging server, I don’t have any files in the directory that nginx in serving besides a test.php running phpinfo();
Alright, the issue is that your webserver uses a site domain as its own hostname.
To fix the WordPress loopback connection issue, the hostname has to be changed, e.g. to web-3.some-domain.tld or web-3.web-agency.tld. Then it will not resolve those requests to 127.0.0.1, and the issues should be fixed with it.
You can turn CloudFlare back on again, but you need to change the hostname of the server to something that is different to the site domains.
It may be a good idea to add this to Trellis documentation, that the usage of a site domain as Trellis web server hostname should be avoided. 
3 Likes
wordpress_sites:
alliancechemical.com:
site_hosts:
- canonical: alliancechemical.com
I need to change alliancechemical.com to something else?
The hostname of web server itself! Not of the WordPress site.
When you invoke hostname you can see the current hostname of the web server.
Changing the hostname should be relatively easy – but still be careful to not mess something up. Have a console/terminal access ready in case SSH has some hiccups.
Edit: I also noted that at the end of /etc/hosts of the web server there is a mapping for the public-IP-address to the WordPress hostnames. But the priority inside /etc/hosts is top to bottom, so the default localhost (127.0.0.1) will win, hence the web server shouldn’t have a hostname that is the same as a WordPress site domain.
How do I rename a Droplet or change its hostname? :: DigitalOcean Documentation.
I can follow this to change the hostname? I want to change staging server or production or both
Yes, this looks good, also because the guide is specific to Digital Ocean Droplets, on which the affected web server runs (I guess, I think I read this somewhere here).
Yes it is a DO droplet
When you changed the hostname of the web server, the WordPress loop back should work correctly for that domain, which resolves the issues.
I for example use something like web-1.web-agency.tld; web-2.web-agency.tld and so on.
Will do! About to do it had to leave work and going to apply the changes as soon as I get home and update here! Youre a life saver tho
