云服务器指定端口连不上？从 ss、防火墙到安全组的排查顺序

业务明明部署好了，本机 curl 也正常，但别的机器就是连不上某个端口：Connection timed out 或 Connection refused。这类问题很少是“网断了”，而是监听地址、本机防火墙、云上安全组某一环没放行。下面按从近到远的顺序排查，命令在 EulerOS、CentOS 7+/8、Ubuntu 20.04+ 上通用。

一、先分清超时和拒绝，别一上来改安全组

从客户端测一次，把现象说清楚：

# 把 192.0.2.10 和 8080 换成实际地址和端口
curl -v --connect-timeout 5 http://192.0.2.10:8080/
nc -vz -w 5 192.0.2.10 8080

常见结果含义不同：

• Connection refused：数据包已经到达对端，但没有进程在该端口接听，或者对端明确拒绝了。优先查服务有没有起来、监听的是不是这个地址。
• Connection timed out / 一直卡住：更像中途被丢弃，常见原因是安全组、网络 ACL、本机防火墙，或中间还有一层 NAT/负载均衡没有放行。
• No route to host：路由或 ICMP 不可达，要先看 VPC 路由、弹性网卡和本机路由表，而不是先改应用配置。

ping 通不能说明端口通。ICMP 和 TCP 走的是不同规则，很多云环境默认放行 ping、但业务端口要单独开。反过来，有的环境禁 ping，也不代表 TCP 一定不通，所以不要只用 ping 下结论。

如果客户端访问的是域名，先确认解析到的就是这台机器的地址，避免把 DNS 问题和端口问题搅在一起：

getent hosts your.example.com
ss -lntup | head

二、到服务器上看：进程到底有没有在听

登录这台云服务器，先看端口：

ss -lntup | grep 8080

（没有 ss 时可用 netstat -lntup。）关注三件事：

1. 有没有这一行。没有，说明服务没起来，或听的根本不是这个端口。回头查进程、容器端口映射、配置文件里的 listen / port。
2. 本地地址是 0.0.0.0、*、[::]，还是 127.0.0.1 / ::1。绑在回环地址上时，只有本机能连，其他机器都会失败。很多框架默认 localhost，部署到云上之后最容易踩这个坑。
3. 进程是不是你以为的那个。ss -lntup 会带上进程名和 PID，避免看错了旁边另一个服务。

如果监听地址不对，改应用配置，让它绑到 0.0.0.0 或实际网卡地址，然后重启服务再测本机：

curl -v --connect-timeout 3 http://127.0.0.1:8080/
curl -v --connect-timeout 3 http://$(hostname -I | awk '{print $1}'):8080/

本机回环能通、本机网卡地址不通，优先怀疑服务只绑了 127.0.0.1。本机网卡地址能通、别的机器不通，再往防火墙和安全组看。

容器场景还要多确认一层：容器内监听不等于宿主机暴露。用 docker ps 或对应编排工具看端口映射，是 0.0.0.0:8080->8080/tcp 还是只映射到了 127.0.0.1:8080。

三、查本机防火墙，别只看云控制台

即使安全组已经放行，本机 firewalld、iptables、nftables 或 ufw 仍可能丢掉入站包。

先看当前生效的过滤器：

# firewalld
systemctl is-active firewalld
firewall-cmd --state
firewall-cmd --list-all

# ufw（常见于 Ubuntu）
ufw status verbose

# 直接看内核规则（firewalld/ufw 底层往往也是这些）
iptables -L INPUT -n -v --line-numbers
nft list ruleset

判断要点：

• 默认策略如果是 DROP 或 REJECT，没有对应放行规则就会表现为超时或拒绝。
• 有的环境同时开了 firewalld 和手写 iptables，改了一处另一处仍在拦截。以实际生效的规则为准，不要只看某个工具的“已添加”提示。
• 改规则后确认已经生效：firewalld 用 --permanent 之后还要 firewall-cmd --reload；ufw 要看到规则已进入 Status: active 的列表。

临时验证时，可以先对单一端口放行，而不是关闭整个防火墙。放行后从客户端再测一次；如果立刻能通，根因就在本机防火墙。

四、再看云上的安全组和网络 ACL

安全组是云服务器最常见的拦路虎，尤其是“出方向全开、入方向只开了 22”的默认模板。核对时注意：

1. 方向：访问业务端口看的是入方向规则，不要只确认出方向。
2. 协议和端口：TCP 8080 和“全部协议”不是一回事；UDP 服务用 TCP 规则放行无效。
3. 源地址：写成某个办公网段后，家里或另一台云主机访问会被丢弃，现象通常是超时。
4. 网卡绑定：规则加在安全组里了，但弹性网卡绑的是另一个安全组。到控制台核对这张网卡实际关联的是哪一组。
5. 网络 ACL：部分 VPC 还配了子网级 ACL，它是无状态的，放行入站时还要放行对应的回程端口。安全组看起来没问题、却仍然超时，值得查 ACL。

改完安全组一般很快生效，但不要默认“一定是秒级”。再从客户端测时，用 nc 或 curl 看 TCP 是否能建立，比反复 ping 更有意义。

如果前面还有负载均衡或 NAT 网关，还要确认监听端口、后端健康检查和转发协议是否一致。健康检查失败时，负载均衡可能根本不会把流量打到这台机器。

五、还不通时，用抓包确认包有没有到达

到这一步，建议在服务器上抓包，避免继续猜测：

# 只看目标端口，持续几秒后从客户端再连一次
tcpdump -ni any port 8080

判断方法很直接：

• 客户端重试期间这里没有任何包：流量没到这台机器。回头查安全组、ACL、公网 IP/弹性 IP 是否绑对、是否走了另一台负载均衡。
• 能看到 SYN，但没有应用的 SYN-ACK：服务没在听、绑错地址，或本机防火墙在接收之后丢弃了。
• 能看到完整握手，但应用层没有数据或立刻断开：问题已经不在“端口通不通”，而在应用、证书、反向代理或上游。

IPv6 也值得顺手看一眼。客户端如果解析到 AAAA 记录，而服务只监听了 IPv4，也会出现“有的网络能通、有的不通”。ss -lntup 里同时看 0.0.0.0 和 [::]。

六、改完记得留下可复核的结论

排通之后，把下面几件事记下来，下次不用从头猜：

• 服务监听地址和端口（来自 ss -lntup）；
• 本机防火墙放行的协议与端口；
• 安全组和网络 ACL 的入方向规则、源地址范围；
• 若经负载均衡，记录监听端口和健康检查状态。

大多数“端口连不上”都能在这四层里定位到：服务没听或听错地址、本机防火墙丢掉、安全组/ACL 未放行、流量根本没打到这台机器。按这个顺序走，比来回开关安全组或重启服务要快得多。