阿里云服务器上的服务已经启动，浏览器却打不开页面，这种情况很常见。多数时候服务本身没有故障，问题出在端口没有真正对外放通。下面以一台运行 Nginx 的 ECS 为例，说明阿里云端口不通时可以按什么顺序排查。
先弄清外部请求要过的两道关
外部访问一个端口，请求通常要穿过两道关。第一道在云平台上，就是 ECS 绑定的安全组，它决定哪些来源的流量能进入实例。第二道在实例内部，包括系统防火墙（比如 CentOS 系常用的 firewalld，Ubuntu 上的 ufw），以及服务自身的监听地址。两道关都要放行，任何一道拦住，外部都连不上。
排查时要把两层分开看。安全组改了不生效，很可能是系统防火墙还在拦；反过来，系统防火墙放开了，控制台里没有对应的入方向规则，照样不通。
案例：Nginx 装好后 80 端口打不开
某个小团队在杭州地域购买了一台 ECS，装好 Nginx 后，在服务器本机执行 curl 能拿到页面，用公网 IP 访问却一直超时。他们的排查过程大致如下：
- 进入 ECS 控制台，找到实例绑定的安全组，查看入方向规则。规则里只放行了 22 端口，没有 80。
- 新增一条入方向规则，协议选择 TCP，端口范围填 80/80。授权对象按实际访问范围填写，不要图省事直接填全网段。
- 规则保存后仍然不通。登录服务器执行 systemctl status firewalld，发现系统防火墙已经开启，且没有放行 80。补上放行规则后，页面恢复正常。
这个案例说明，控制台里的规则只是一层。规则改对了，系统内部那一层还要单独检查。
先在服务器上确认服务真的在监听
排查网络之前，先确认服务确实绑定在目标端口上。在服务器上执行 ss -tlnp，可以看到每个端口对应的进程和绑定地址。如果只看到 127.0.0.1:8080，说明服务只接受本机请求，外部再怎么放通也没有用。这时需要修改服务的监听配置，比如 Nginx 的 listen 指令，让它监听 0.0.0.0 或具体的内网地址。
从外部机器验证时，可以使用 telnet 公网IP 80 或 nc -zv 公网IP 80。连接成功，说明整条链路是通的。如果一直超时，多半是安全组或系统防火墙在中途丢弃了请求；如果直接返回 connection refused，通常是服务没有在这个端口监听，或者防火墙明确拒绝了连接。两种现象指向的方向不同，不要混在一起判断。
排查顺序可以这样走
实际操作时，建议按服务监听、系统防火墙、安全组的顺序逐层确认，每一步都用命令看结果，不要只凭控制台页面判断。
- 在服务器上执行 ss -tlnp，确认服务监听在 0.0.0.0 或内网 IP 上，而不是 127.0.0.1。
- 执行 firewall-cmd –list-all（firewalld）或 ufw status（ufw），查看系统防火墙是否放行了目标端口。
- 回到控制台，检查 ECS 绑定的安全组，确认入方向规则覆盖了目标端口，且授权对象包含你的访问来源。
- 从外部机器再用 telnet 或 nc 测试一次。连接成功，问题即已解决。
开放端口时别图省事
排查时最省事的做法，是把授权对象直接设成 0.0.0.0/0，这样整个互联网都可以尝试连接该端口。对公开的 Web 服务来说，这或许还能接受；对数据库就很危险了。MySQL 的 3306、Redis 的 6379 不应直接暴露在公网上。这类服务一旦被扫描到，弱口令或未授权访问都可能被利用。
比较稳妥的做法有几条：
- 只开放业务真正需要的端口，用到哪个开哪个，不做批量放通。
- 授权对象尽量限定到固定的办公出口 IP，或者同一 VPC 内的网段。
- 数据库和缓存优先走内网。应用服务器与数据库放在同一 VPC 内，连接地址使用内网 IP。临时需要远程维护时，用 SSH 隧道转发，用完就关。
- 定期清理安全组里已经没人用的历史规则。规则越积越多，后面没人敢动，排查时也更难分辨哪条是必需的。
小结
阿里云端口访问不通时，先不要反复修改安全组。先确认服务在正确地址上监听，再检查系统防火墙，最后核对安全组规则，每一步都用命令验证。按这个顺序走，通常很快就能找到卡在哪一层。端口开得越精准，之后需要维护的东西也越少。
