Reverse proxy with nginx + app on Galaxy

I have a Wordpress site and a meteor app. Both should be served from the same URL.
WP: (demo:
Meteor: (demo:

For the beginning I am trying only http.

My /etc/nginx/sites-available/default configuration:

server {
  listen 80;


  location / {
    proxy_pass; #wordpress

  location /app {
    proxy_pass; #galaxy

I also added the domain „" as a domain in galaxy.

I am getting a 502 Bad Gateway response. Any help?

1 Like

Hi, I’m facing a similar problem - did you manage to sort this out some how by any chance @paul_bo ?

In the Meteor app, did you set that URL as ROOT_URL? When Meteor lives under a path, this is likely to be the problem.

(Unless the Nginx error returns when you visit the Wordpress site)

Hi @illustreets, thanks for your reply. In my case the meteor app is on the base domain (eg. and the blog is ‘1 level’ down under /i/ (eg. - So I set the ROOT_URL to the URL the base domain:

"ROOT_URL": ""

This setup worked well on a different hosting ( / 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

And you get the 502 error even though the config in Nginx is:

location / {
    proxy_pass; # meteor app

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.

I hope you get to solve the issue.

Yes I contacted them - waiting for a reply :slight_smile:

No, my Nginx config would point to the Galaxy URL i.e.

 location / {
    proxy_pass; # meteor app

 location /i/ {
    proxy_pass; # server URL serving PHP based CMS

Since is the address of the reverse proxy server (which decides whether to load content from meteor app, or the blog based on the URL)

Sorry, obviously.

Well, I guess it is worth waiting for the guys at Galaxy to respond.

1 Like

@illustreets @paul_bo - Galaxy support came back to me with a solution that worked for me. I needed to add the option proxy_ssl_server_name on; to my nginx config (as documented at

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.”

So my config now looks something like this:

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;

        proxy_redirect off;

        # Handle Web Socket connections
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_ssl_server_name on;

Thank you for getting back with the solution. I’m sure this will be useful to many

1 Like

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?