1

There are several domain names bound to my server.

I need to redirect requests like domain.com or domain.com/ to app.domain.com.

Following is what I added in my app config:

server {
   listen 80;
   server_name main_domain.com domain.com;

   ... other lengthy directives ...       

   location = / {
      if ($host ~ 'domain.com') {
          return 302, http://app.domain.com;
      }
   }

   location / {
       try_fies $uri @app;
   }

   location @app {
       include uwsgi_params;
       uwsgi_pass unix:path_to/uwsgi.sock;
       uwsgi_intercept_errors on;
   }
} 

This made the redirection works, but requests to / of my other domain names all returned 404.

What can I do to make Nginx go on matching locations?

5
  • return 302, app.domain.com; ---> typo?
    – masegaloeh
    Dec 9, 2014 at 12:06
  • @masegaloeh Yes, it should include a scheme. Dec 9, 2014 at 12:11
  • 1
    @Satoru.Logic You also need to remove the ,. Another thing : the regex will match *domain.com* so you should use ^domain.com$ instead of domain.com. Dec 9, 2014 at 12:24
  • I provided and answer with what I feel is a better approach. If you prefer, recognise that as soon as the request enters the = / location block no other location block will apply. It should then be obvious why you're getting a 404 for http://other-host.com/.
    – AD7six
    Dec 9, 2014 at 13:35
  • @AD7six Thanks. When I got 404 for the other domain names, I suspected a request processing stopped once it entered a location block, and I began to search for something like a continue for this block. I'll try your solution and see if it works :) Dec 10, 2014 at 1:34

2 Answers 2

1

If I understand the question correctly the objective is:

  • http://domain.com/ -> 302 -> http://app.domain.com/
  • http://app.domain.com/ -> static file of @app response
  • http://main_domain.com/ -> static file of @app response
  • http://domain.com/something -> static file of @app response
  • http://app.domain.com/something -> static file of @app response
  • http://main_domain.com/something -> static file of @app response

(not sure why main_domain and domain are used in the config; yet domain and app.domain is used in the question - if you're using a wildcard dns you are currently relying on the implicit default_server).

Assuming that's correct: Use two server blocks.

E.g. put all of this in a file:

# /etc/nginx/common.conf
... other lengthy directives ...       

location / {
   try_fies $uri @app;
}

location @app {
   include uwsgi_params;
   uwsgi_pass unix:path_to/uwsgi.sock;
   uwsgi_intercept_errors on;
}

And include it in both server blocks:

server {
   listen 80;
   server_name domain.com;

   location = / {
      return 302 http://app.domain.com;
   }

   include common.conf;
}

server {
   listen 80;
   server_name main_domain.com app.domain.com;

   include common.conf;
}

That avoids using an if testing the hostname, and makes it clearer what is going to happen for each host.

0

If I were you I'd alter that config somewhat to return the requested URI but on the subdomain you want to redirect to, by using a rewrite rule to do so (you're nearly there);

server {
   listen 80;
   server_name main_domain.com domain.com;

      if ( $host = 'domain.com' ) {
          rewrite ^ http://app.domain.com$request_uri? permanent;
      }
} 

Note that I have taken that out of your location directive (so it applies to all incoming URI requests).

Edit: Also note that I've only left the if statement under the assumption that you may only want to rewrite specific URLs - if that is not the case, please put the rewrite in the main body of the config for those server names.

2
  • I doubt that's what Satoru.Logic wants, otherwise why have a location = / (ONLY the root url, not urls with a path) location block in the question. Should that actually be what's desired it'd be much better to use 2 server blocks. Using rewrite permanent instead of return 301 x doesn't change anything - except the http status code.
    – AD7six
    Dec 9, 2014 at 13:18
  • If it is not what (s)he wants, then fair enough; it was merely my interpretation of the question and the listed desired URLs, and a suitable solution for this interpretation.
    – BE77Y
    Dec 9, 2014 at 13:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .