安全组放行了端口还是不通

安全组规则加好了，连接依然超时，此时第一怀疑对象应该转向服务器内部——系统防火墙这一层经常被漏掉。 ## 云上和系统里各有一道门 安全组是云平台在虚拟网络层做的包过滤，位于操作系统之外；firewalld、ufw、iptables 这些系统防火墙跑在机器内部。流量要先后穿过两道门，任何一处拦截都表现为连不通。控制台放行了 8080，系统里 firewalld 仍在默认区域拦着，是这类故障里最常见的卡点。 两边互不覆盖：安全组变更即时生效，系统防火墙改动只影响本机。以为在控制台改了规则、系统里的防火墙会跟着放行，是最常见的误会。 ## 按固定顺序往下查 第一步确认服务真的在监听： ss -lntp | grep 8080 没有输出说明是服务本身没起来，跟防火墙无关。第二步看系统防火墙状态： firewall-cmd --state firewall-cmd --list-all 列表里没有目标端口就补上： firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --reload Ubuntu 系统换成 ufw status、ufw allow 8080/tcp。改完记得自查：规则加在错误的区域（zone）里等于没加，firewall-cmd --get-active-zones 看网卡落在哪个区，加对了区再验证。 第三步才回到云控制台核对安全组：方向（入方向）、协议（TCP）、端口、来源 IP（0.0.0.0/0 或指定网段）四项逐一对照，差一项都不通。来源限制多说一句：图省事写 0.0.0.0/0 等于向全网开门，SSH、数据库这类管理端口尽量收敛到固定出口 IP 段。 ## 一个容易误判的现象 telnet 显示 connection refused 和超时含义不同：refused 说明包到达了机器但端口没人监听，大概率是服务没启动；超时更像中间某层把包丢弃了，防火墙和安全组的嫌疑更大。利用这个差异能快速定位断点在哪一层。 两层防护的存在不是多余：安全组挡在入口适合做粗粒度管控，系统防火墙适合跟随应用细调。排查时从里向外走一遍，断点自然浮出来。如果两层都放行了还不通，剩下的嫌疑是服务绑定地址与端口本身，回到 ss -lntp 那一步重新对表。