更新：
我向 DO 提交了一张工单，并被告知他们已自动关闭端口 8083，因为 VestaCP 漏洞允许 root 访问 droplet。虽然我很高兴找到了导致我的问题的原因，但我对 DO 感到失望，因为他们没有联系他们的用户告知他们这件事。我在这个问题上浪费了好几个小时，这些时间我再也找不回来了。
在我的 DO 服务器上，我已将 API 绑定到端口 8083，直到今天它都正常工作。现在每当我尝试连接到我的 API 时，连接都会超时。我尝试使用连接到该端口，nc -zv host port但它也挂断了。
奇怪的是，更改 API 中的端口，重新编译并运行它，一切正常。除 8083 外，几乎所有其他端口都可以正常工作。
我ssh进入盒子，然后运行，nc -zv localhost 8083收到连接成功消息。我认为没有任何防火墙阻止它，因为我运行了它service iptables status，它显示iptables.service未运行。
所以，现在我有两个选择，要么为我的 API 使用不同的端口（这很麻烦，因为端口被硬编码到我使用该 API 的 Android 应用程序中），要么解决这个问题。
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN 1328/sshd
tcp6 0 0 :::8086 :::* LISTEN 1586/api1
tcp6 0 0 :::3306 :::* LISTEN 1343/mysqld
tcp6 0 0 :::2222 :::* LISTEN 1328/sshd
tcp6 0 0 :::8080 :::* LISTEN 1583/api2
tcp6 0 0 :::8082 :::* LISTEN 1574/api3
tcp6 0 0 :::8083 :::* LISTEN 1801/api4
tcp6 0 0 :::8084 :::* LISTEN 1571/api5
tcp6 0 0 :::8085 :::* LISTEN 1577/api6
可能是什么问题呢。
答案1
绑定到 tcp 端口的服务不接受连接的原因有很多。也许应用程序内的 ACL 只接受来自特定 IP 的连接。也许服务需要守门人连接来首先开始某种会话，然后才能在该端口上接受其他连接。也许这是一项仅允许有限数量连接的服务，并且已满。也许 iptables 正在阻止或过滤连接……诸如此类。
也许您应该通过查看 PID 来查看哪个进程绑定了端口netstat -an -p，然后查看该进程是什么。