Nginx server_name command being ignored

Hi, I’m running ubuntu server 12.04 and the latest version of nginx. The
problem I am having is that nginx seems to be ignoring the server_name
command, I am able to access the server by going to the IP address of
the
server or by going to the server’s name (http://ubuntuserver/) but
http://test/ will give me nothing, no connection, not even an error
page. I
have checked that the website file (in enabled-sites) is included in the
nginx.conf file and I have correctly restarted nginx having changed
settings. I have tried with the whole server block stripped down to just
the
server_name designation and still I can’t get anything at http://test/
and
in this case I get an expected error page on http://ubuntuserver/

I can only deduce that for some reason the “server_name” command is
being
ignored!

If anyone could give me any advice with regards to this then it would be
much appreciated.

Code from file “www” in “enabled-sites”:

server {
add_header Cache-Control public;
access_log /var/log/nginx/access.log main buffer=32k;
error_log /var/log/nginx/error.log error;
expires max;
limit_req zone=gulag burst=200 nodelay;
listen 127.0.0.1:80 sndbuf=128k;
root /usr/share/nginx/html;
server_name test;
}

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,234028,234028#msg-234028

server_name designation and still I can’t get anything at http://test/ and
in this case I get an expected error page on http://ubuntuserver/

I can only deduce that for some reason the “server_name” command is being
ignored!

Is there a resolver (DNS or /etc/hosts) for test?

What does ping test gives?

–appa

On 14 December 2012 13:01, constable1 [email protected] wrote:

I can only deduce that for some reason the “server_name” command is being
ignored!

I really doubt it is. It’s an absolute cornerstone of how nginx works.

a) Does your machine resolve the correct IP address when asking your
hostsfile/DNS/etc for “test”? server_name doesn’t automatically point
your browser towards the correct machine …

b) The first server{} stanza for an IP:port pair is the default one
served when a request comes in on that IP and port, and the Host
header doesn’t match /another/ server_name configured elsewhere for
that same IP and port. Unless there’s a dedicated default server …

You may wish to set up a sacrificial default server to make nginx’s
behaviour more obvious.
This is roughly what I have (typed but not tested, FYI):

server {
listen 80 default_server;
server_name _;
return 400 “Server not configured”;
}

HTH,
Jonathan

Jonathan M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

I’ve tried pinging http://test/ and get nothing, I’ll have a go with
your
suggestion Jonathan and report back!

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,234028,234032#msg-234032

On 14 December 2012 13:12, constable1 [email protected] wrote:

I’ve tried pinging http://test/ and get nothing

Just do “ping test”. Not “ping http://test/

I’ll have a go with your
suggestion Jonathan and report back!

My suggestion for a default server will not fix your inability to
resolve the site’s name. It’s just a sanity thing you’ll find useful
if you set up more server{}s over time. You need to fix the DNS/etc
issue, once you prove it exists as per the above.

Jonathan

Jonathan M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

On Fri, Dec 14, 2012 at 01:13:44PM +0000, Francis D. wrote:

On Fri, Dec 14, 2012 at 08:01:33AM -0500, constable1 wrote:

Hi there,

What is the output of

curl -i http://test/

?

My guess is that your browser fails to resolve the name to the correct
address, and so never talks to nginx in the first place.

Oh, if that is the case, then you can still test the nginx side without
fixing name resolution by looking at the output of

curl -i -H Host:test http://127.0.0.1/

and confirming that it is what you expect.

f

Francis D. [email protected]

Hi Jonathan, Francis,

I’ve just tried on the server “ping test”, and I get no packet loss, it
all
seems to be looking fine. I also tried “curl -i http://test/” and I get
the
output as the code that makes up the html of my page, so it appears that
nginx is working fine, but when I try going to http://test/ on another
machine on my home network then I get nothing, I agree that this must be
some kind of DNS issue here, but how does one go about fixing it?

Cheers,
Matt

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,234028,234062#msg-234062

On Fri, Dec 14, 2012 at 08:01:33AM -0500, constable1 wrote:

Hi there,

I am able to access the server by going to the IP address of the
server or by going to the server’s name (http://ubuntuserver/) but
http://test/ will give me nothing, no connection, not even an error page.

What is the output of

curl -i http://test/

?

My guess is that your browser fails to resolve the name to the correct
address, and so never talks to nginx in the first place.

If that is the case, make the name resolvable – put it in DNS or
/etc/hosts, for example – and retry the curl command.

If it does not show what you expect, describe that output too.

f

Francis D. [email protected]

Jonathan, I’ve added to the host file of my server 127.0.0.1 test, but
still
have no luck locally. I have also tried port forwarding from my router
(port
80 to port 80) and am unable to then connect to my server using my
public IP
address. Do you know if there are any forums which could help me in this
regard?

Cheers

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,234028,234064#msg-234064

On 14 December 2012 23:54, constable1 [email protected] wrote:

Hi Jonathan, Francis,

I’ve just tried on the server “ping test”, and I get no packet loss, it all
seems to be looking fine. I also tried “curl -i http://test/” and I get the
output as the code that makes up the html of my page, so it appears that
nginx is working fine, but when I try going to http://test/ on another
machine on my home network then I get nothing, I agree that this must be
some kind of DNS issue here, but how does one go about fixing it?

Work put how the machines should be resolving “test” to an IP
address, and add entries so that they can.
This may be your hosts file, if you’re doing internal, LAN-only
development, or a DNS server somewhere.

This is somewhat of out of scope for the nginx list now, though … :slight_smile:

HTH,
Jonathan

Jonathan M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

Hi Francis,

I am trying to access the web server from a bunch of windows machines (I
don’t have any linux desktops). My /etc/hosts file already reads:
127.0.0.1 localhost
127.0.1.1 ubuntuserver
192.168.1.93 test

Where the final address is the local address of the server. When I do
the
curl operation from the server on http://test/ then I get the index.html
page back, which is encouraging, but when I try to ping it from any of
my
windows machines then I get nothing.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,234028,234073#msg-234073

On Fri, Dec 14, 2012 at 06:54:58PM -0500, constable1 wrote:

Hi there,

I also tried “curl -i http://test/” and I get the
output as the code that makes up the html of my page, so it appears that
nginx is working fine, but when I try going to http://test/ on another
machine on my home network then I get nothing,

Exactly the same as the last time:

What is the output of

curl -i http://test/

? Do that from whatever machine you want things to work from. The output
is unlikely to be “nothing”, and is likely to give an indication of the
first problem.

And you can still test the nginx side without fixing name resolution by
looking at the output of

curl -i -H Host:test http://127.0.0.1/

where “127.0.0.1” should be replaced with “an ip address that the nginx
server is listening on”.

Note that 127.0.0.1 is a special address which means (roughly) “this
machine only”. And so is unlikely to work from any other machine.

The server{} block that has “server_name test” would need to “listen”
on a non-127.0.0.1 address for it to be accessible

I agree that this must be
some kind of DNS issue here, but how does one go about fixing it?

“Big” fix is “whatever your network does”. “Small” fix is /etc/hosts.

f

Francis D. [email protected]n.invalid

Francis, forgive me, I was accidentally editing the host file on the
wrong
machine, stupid mistake, I’ve now got it sorted and working for a public
IP
now.

Thanks for all of your help Jonathan, Francis!

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,234028,234075#msg-234075

On Sat, Dec 15, 2012 at 07:01:45AM -0500, constable1 wrote:

Hi there,

Francis, forgive me, I was accidentally editing the host file on the wrong
machine, stupid mistake, I’ve now got it sorted and working for a public IP
now.

No worries; “sorted and working” is good news…

Good stuff,

f

Francis D. [email protected]

On Sat, Dec 15, 2012 at 06:32:07AM -0500, constable1 wrote:

Hi there,

I am trying to access the web server from a bunch of windows machines (I
don’t have any linux desktops). My /etc/hosts file already reads:
127.0.0.1 localhost
127.0.1.1 ubuntuserver
192.168.1.93 test

/etc/hosts is for local-to-this-machine name resolution. It is the
client
machine – the one running the web browser – that needs to resolve the
name “test” to the ip address.

So if you try on a windows machine, you must have the “test” entry in
the /etc/hosts file on that windows machine. Searching the fine web
should tell you exactly which file that corresponds to on the version
of windows that you are using.

Where the final address is the local address of the server. When I do the
curl operation from the server on http://test/ then I get the index.html
page back, which is encouraging, but when I try to ping it from any of my
windows machines then I get nothing.

When you type “curl -i http://test/” from a command shell on any one
windows machine, you get immediately returned to the prompt with no
other output? Likewise when you use the other curl command suggested?

That is unexpected to me and I do not know how to proceed.

f

Francis D. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs