![无法连接到端口 80,所有连接都卡在 SYN_RECV](https://linux22.com/image/536614/%E6%97%A0%E6%B3%95%E8%BF%9E%E6%8E%A5%E5%88%B0%E7%AB%AF%E5%8F%A3%2080%EF%BC%8C%E6%89%80%E6%9C%89%E8%BF%9E%E6%8E%A5%E9%83%BD%E5%8D%A1%E5%9C%A8%20SYN_RECV.png)
我无法通过端口 22 或 80 连接到我的服务器。当我运行 netstat 时,我看到有几个连接,它们都卡在 SYN_RECV 中。谷歌搜索显示大部分问题都是关于 DDOS 的。由于连接很少,这似乎不太可能(尽管我在共享主机(slicehost)上)。
还有什么原因造成这种情况?
答案1
检查您的/etc/hosts.deny 没有损坏。我曾经遇到过这种情况,并导致网络服务挂起的极其奇怪的问题。
检查防火墙规则 ( sudo /sbin/iptables -nvL
)。您可能将防火墙配置为允许传入连接但阻止传出连接,从而导致传入连接挂起。
你能在机器本身上连接到这些端口吗?例如,如果你登录到系统,运行会有telnet localhost 80
什么作用?
日志文件中是否有任何有趣的内容,例如/var/log/secure
或/var/log/messages
?
答案2
我以前见过一次这种情况,那是一个奇怪的时间问题。连接卡在半开状态(SYN_RECV 的意思)并且挂起。最终导致问题的原因有两个:
- 服务器的网络掩码不正确(/16 而不是 /24)
- 服务器子网上有两台设备发出代理 ARP 数据包
当时的情况是,初始连接到达服务器。服务器会回复,但在回复之前,它必须先找出目标的 MAC 地址。由于网络掩码配置不正确,它会尝试对 IP 地址进行 ARP 处理。然后路由器发出代理 ARP,表示它有该地址,因此服务器发送了 SYN/ACK 数据包。在发送数据包和回复客户端的 ACK 之间,我们的负载均衡器还发出了代理 ARP 数据包。服务器尽职尽责地更新了其 ARP 表。因此,当它回复 ACK 数据包时,它通过完全不同的设备进行回复。该设备是有状态的,没有此 ACK 数据包的连接,因此将其丢弃。因此,客户端的连接似乎处于半开状态。
答案3
我不确定问题是什么,但是我的托管服务提供商将我的虚拟机移至新机器,问题就解决了。
答案4
大多数情况下,防火墙是罪魁祸首。请执行service iptables stop
并service ip6tables stop
。
如果停止服务不起作用,则执行 iptable flush。
iptables --flush