Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm unable to connect to my server on port 22 or 80. When I run netstat, I see that there are a few connections, all of them stuck in SYN_RECV. Googling revealed mostly questions about DDOS. Since there are very few connections this seems unlikely (although I am on a shared host (slicehost)).

What else could be causing this?

share|improve this question

Check that your /etc/hosts.deny isn't corrupted. That happened to me once and caused extremely bizarre problems with hung netowkr services.

Check your firewall rules (sudo /sbin/iptables -nvL). You could have your firewall configured to allow incoming connections but block outgoing connections, causing incoming connections to hang.

Can you connect to those ports on the machine itself? For example, if you are logged on to the system, does running telnet localhost 80 do anything?

Anything interesting in logfiles like /var/log/secure or /var/log/messages?

share|improve this answer

The one time I've seen this before it was a strange timing issue. The connections were getting stuck in the half-open state (what SYN_RECV means) and hanging. What ended up being the problem was two fold:

  1. The server had an incorrect netmask (/16 instead of /24)
  2. There were two devices on the server subnet that issue proxy-ARP packets

What was happening was that the initial connection comes to the server. It replies but before it can do that it has to figure out the MAC address of the target. Due to the incorrectly configured netmask it attempts to ARP for the IP address. The Router then issued a proxy-arp saying it had that address, so the server sent the SYN/ACK packet. Between the time the packet was sent and when it came time to reply to the ACK from the client, our load-balancer had ALSO issued a Proxy ARP packet. The server dutifully updated its ARP table. So when it replied to the ACK packet it did so through a completely different device. The device was stateful, and didn't have a connection for this ACK packet so dropped it on the floor. Thus the connection seemed half-open on the client end.

share|improve this answer
Wow that's a pretty crazy scenario I hadn't considered (and I've never seen!) – Phil Hollenback Jan 22 '11 at 7:14

I'm not sure what the problem was, but my hosting provider moved my VM to a new machine and the problem was resolved.

share|improve this answer

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.