Second domain config does not redirect www traffic

Server NGINX
1

Hello, I have ngnix installed to serve up to websites. The first one is
behind is behind SSL and should redirect everything to
https://EXAMPLE1.com.
This works perfectly as for the second website, its only being hosted on
http. All www traffic should redirect to non-www but it fails.

Here is my nginx config: http://pastie.org/private/ziromp4jqkbxehk5xjiha

Does conf loading order matter? These are the files as they appear in
the
nginx conf directory:
sites-enabled/EXAMPLE1.conf
sites-enabled/EXAMPLE2.conf

Could this be a DNS issue?
www.EXAMPLE1.com, www.example2.com, example1.com, example2.com all have
A
Host name records defined. Should I use a Cname record for the www.*
names

Here is what works and what fails:
WORKS - http://www.EXAMPLE1.com redirects to https://EXAMPLE1.com
WORKS - http://EXAMPLE1.com redirects to https://EXAMPLE1.com
WORKS - https://EXAMPLE1.com

WORKS - http://EXAMPLE2.com
BROKE - http://www.EXAMPLE2.com fails to redirect to
http://EXAMPLE2.com. I
get a welcome to nginx screen.

Any ideas? Thanks so much for any help that can be provided!

Posted at Nginx Forum:

2

On Thu, Feb 19, 2015 at 01:59:03AM -0500, macmichael01 wrote:

Here is my nginx config: http://pastie.org/private/ziromp4jqkbxehk5xjiha

It is usually better to include the config in the mail; that url is
unlikely to be accessible wherever the mail archives are read.

But I looked at it anyway.

Your config is syntactically correct, but semantically incorrect.

You’re missing a semicolon on line 31.

server {
listen 80;
server_name www.EXAMPLE2.com
return 301 http://EXAMPLE2.com$request_uri;
}

This defines a port 80 listener with four server_name values and no
extra handling for requests.

(See also line 6.)

Does conf loading order matter?

If you use directives that care about order, yes. If you let nginx use
order to determine defaults, yes. Otherwise, no.

And current nginx loads “*”-matches alphabetically.

Could this be a DNS issue?

If your log file shows that the request is getting to nginx, no.

f

Francis D. [email protected]

3

Thanks! The missing semicolon fixed.

Posted at Nginx Forum: