Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have an nginx server running on ubuntu 12.04 that serves http through port 80 and https through port 443.

Everything works fine if I access it from the same computer via localhost, or the local IP If I try to access the server from another computer in the same VLAN it does not work for http; it works for https. I have changed my nginx configuration to also listen to port 8000 for http; I can then access http from the other computer in the same VLAN via "".

I also have a web server running on port 80 on a windows machine and can access it from another device in the same VLAN, therefore the router is not blocking incoming http traffic.

The nginx process is run by root. I have used tcpdump and I see that packets are arriving to Ubuntu: > and that some response is being given > (I do not know what the response is though). There is no request arriving at the nginx web server (I have checked the access log).

I have iptables empty. I have unsuccessfully tried to find a solution for a long time to this, it has now become a matter of happiness or bitterness :).

share|improve this question
netstat -ntlp will show you if nginx is listening on Addsing -s 0 and -w examplefile.pcap will allow to store http trafic in examplefile.pcap –  user130370 Aug 18 '12 at 14:25
yes, it s listening to all addresses in port 80, I get this: I have also run netstat -ntlp -s 0 and can see (among other things) this for TcpExt: 41814 packet headers predicted 6789 acknowledgments not containing data payload received 5175 predicted acknowledgments 1 times recovered from packet loss by selective acknowledgements ... I can not figure out how to use this information to solve my problem though... –  Eduard Aug 18 '12 at 15:33
Sorry I meant -s 0 and -w examplefile.pcap to tcpdump, not netstat. –  user130370 Aug 18 '12 at 16:37
Ok, I tried the command but can not read much of the file (most of the characters are special characters; I have opened the file with gedit and encoding UTF-8, but there is not much to read). –  Eduard Aug 18 '12 at 17:54
Usually, output files from tcpdump can be read with wireshark. –  user130370 Aug 18 '12 at 17:58

1 Answer 1

This is not really a solution, but comments are gettting too big.

Now you might want to know if the problem comes from os/network or from nginx.

One way to achieve this is :

  • Shut down nginx and check there is no remaining process (I guess your server is not already in production).

  • Start netcat on port 80. Can be nc -l -p 80 but depends which netcat you use

  • From another box type telnet 80 and start typing ramdom stuff. The random stuff should appear in the terminal where you started netcat. If not, try capturing traffic with tcpdump again.

If you can't reproduce your RST, ACK problem with netcat, nginx is likely to be the problem.

share|improve this answer
I have tried to telnet from another device to port 80 and listen with netcat as you suggested (nginx was not listening to port 80 any more). I can not see any output in netcat and when I open the .pcap file with wireshark I see that RST, ACK packets are given as response. If I telnet and open netcat with port 81 everything works! Maybe there is another program/utility that blocks port 80? I am using ubuntu 12.04 desktop. –  Eduard Aug 19 '12 at 7:44
If port 80 was bound by another process, netcat would produce error message like "Can't grab with bind". Double chack iptables, /etc/hosts.deny, disable selinux. I'm running out of ideas. –  user130370 Aug 19 '12 at 12:18
Oh, just noticed netstat -ntlp: tcp 0 0* LISTEN -. It's strange : Usually it shows the process number. –  user130370 Aug 19 '12 at 12:21
It actually says: tcp 0 0* LISTEN 975/nginx when I do netstat -ntlp, I guess the first time I did not include all the options. /etc/hosts.deny is empty, I disabled apparmor (equivalent to selinux), but the problem did not get solved. Thanks a lot for your help anyways. –  Eduard Aug 19 '12 at 14:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.