This setup worked well on a different hosting (Modulus.io / Xervo.io) but does not work on Galaxy for some reason. Blog still works fine and switching the proxy_pass back to a xervo URL results in the app loading well again. Using a galaxy url fails though
If that’s the case, then I’m not sure what to do next, given that I don’t have your .conf file. It might very well be because of another proxy in front of your app (on Galaxy). I would say, as a Galaxy customer, you should raise a ticket. They are quite fast and very helpful.
Quoting Galaxy support: “Galaxy does not have a single IP per domain, so it can only know which certificate to use in the TLS handshake if it knows which domain will be requested. As the SSL handshake happens before the HTTP request, the Host header is not available and SNI (the TLS feature enabled by that flag) acts as a complement for that purpose.”
We also stuck Nginx in front of our Galaxy instances, but Nginx cached the Galaxy IP for our instance and then it wouldn’t load up till we restarted nginx. Did you ever run into this issue? How are people getting around it?
I’ve had instances where I need to restart nginx because the application wouldn’t load up through nginx and would load up fine when accessed directly via the galaxy URL. TBH I’m not fully active on the project anymore so I didn’t really look into what caused it. So it could very likely be the case you are mentioning. How did you confirm that nginx was caching the galaxy IP please?
Ah ok, Nginx will be listening on ports 80 and 443 because that’s the standard web browser ports for HTTP/S traffic and what all browsers are using. That’s why you dont have to type in meteor.com:80 to visit meteor. Port 80 is assumed.
When you view localhost:3000 you will see the meteor app that is running on port 3000 and when you view :3001 you will see the meteor that is working on there - you are not seeing Nginx. To verify this run a curl -I http://localhost:3000 and check headers. If you don’t see a nginx signature or alternatively if you don’t have terminal you could of determined this from the browser alone by triggering a 404 or error. If you don’t see the nginx error screen it’s direct to meteor still. Nginx will reverse proxy this to the listening port - which by default will be 80/443 depending if you have ssl setup locally
So you’ll find your Nginx is probably already working happily on http://localhost to make it work on http://localhost:3003 you’ll need to change your listen directive to listen on port 3003 and you restart nginx.
For example you must find and change
But it’s best to just run on port 80 because that’s mean you don’t have to type in the port and will avoid issues with users trying to access it and misunderstanding how to type in a port. It’s more userfriendly on the default.
curl -I localhost when Nginx is actually forwarding will return something like the following, note the server line. The first example is autoforwarding to SSL because that’s how I run it.
Make sure your proxy pass directives are resolving because they are set to main_web and group - are you sure those resolve? You should check that, or just use the IP or localhost to ensure that it can be resolved. That would be the first thing I would check here.