服务已经跑起来了，外网却打不开，这是很多人第一次在阿里云上部署时都会遇到的情况。多数时候原因是端口没有放行。下面以云服务器 ECS 为例，说明阿里云开端口的操作步骤、容易踩的坑，以及放行时该注意什么。
先搞清楚两层防护
ECS 实例的端口由两层控制。外层是云上的安全组，在网络层过滤进出实例的流量。内层是操作系统自带的防火墙，CentOS 上一般是 firewalld，Ubuntu 上常见的是 ufw。两层都放行，外部请求才能到达服务。只改了安全组，却忘了本机防火墙，是最常见的漏配。表现通常是怎么改规则都不通。
在控制台添加入方向规则
登录阿里云控制台，进入云服务器ECS，在左侧菜单的网络与安全下找到安全组。选中实例所在的安全组，点击配置规则，切换到入方向标签页，再点击手动添加。需要填写的主要字段如下：
- 授权策略：选“允许”。放行规则才会让对应流量进入实例。
- 协议类型：常用的有自定义TCP、自定义UDP、HTTP(80)、HTTPS(443)、SSH(22)、RDP(3389)等。服务用什么协议，就选什么。如果是自定义端口，选自定义TCP或自定义UDP。
- 端口范围：单个端口如 8080，填 8080/8080。连续端口用斜杠分隔，如 7000/7100。
- 授权对象：填允许访问的 IP 或网段。203.0.113.5/32 只放行这一个地址。0.0.0.0/0 表示所有地址都能访问，除非服务确实要面向公网，否则不要轻易使用。
- 优先级：数值越小，优先级越高。默认值 1 即可，只有和已有规则冲突时才需要调整。
保存后规则通常立即生效，不需要重启实例。
案例：Node.js 接口为什么访问不了
某小团队在 ECS 上部署了一个 Node.js 接口服务，监听 8080 端口。上线当天，测试同事反馈打不开。排查顺序是这样的。先用 ss -lntp 确认服务已经监听 0.0.0.0:8080，说明应用本身没有问题。接着查安全组，发现入方向只放行了 22 和 80，8080 没有配置。新增一条自定义 TCP 规则，端口范围填 8080/8080，授权对象设为办公网出口 IP，测试同事能访问了。但接口仍然超时。最后发现服务器上的 ufw 处于启用状态，执行 sudo ufw allow 8080/tcp 后才彻底通。
这次排查的顺序值得照搬：先看服务是否在监听，再看本机防火墙，最后看安全组。反过来查，很容易在云控制台里绕很久。
验证端口是否真正开放
配置完成后，可以在本地执行 telnet 公网IP 8080。连接成功说明端口可达。也可以用 nc -vz 公网IP 8080。Windows 用户可以用 PowerShell 的 Test-NetConnection 命令测试。
注意一点：如果端口测试是通的，浏览器却报错，问题多半出在应用层，比如路由配置、反向代理或服务本身的报错。这时应该看服务日志，而不是继续改安全组。
别把所有端口都开给公网
运维中最常见的隐患，是把授权对象写成 0.0.0.0/0，同时对 SSH(22)、MySQL(3306)、Redis(6379) 这类敏感端口全部放开。这些端口一旦暴露在公网，很容易遭到暴力破解和端口扫描。建议这样做：
- 只开放业务必需的端口。服务下线或调试结束后，及时删除对应规则。
- 22、3389 等管理端口，授权对象限定为固定办公 IP。办公网出口 IP 变动时，记得同步更新规则，否则自己也可能被挡在外面。
- MySQL、Redis 尽量只允许内网或同安全组的实例访问，不要直接暴露到公网。
- 定期检查安全组，清理不再使用的历史规则。规则越多，越难看清哪一条还在起作用。
阿里云的云安全中心可以辅助发现高风险端口的暴露情况。规则较多时，可以用它做一轮检查。
常见报错与排查方向
- 规则已添加，仍然不通：先确认服务监听的是 0.0.0.0，而不是 127.0.0.1。再检查本机防火墙是否放行了该端口。
- 个别端口被拒绝：查看安全组里是否有优先级更高的拒绝规则。数值小的规则先生效，它可能覆盖你新加的允许规则。
- 使用了负载均衡：需要在 SLB 的监听配置中开放端口，同时确认后端 ECS 的安全组放行了来自 SLB 的流量。只改其中一端，通常还是不通。
- 实例加入了多个安全组：各安全组的规则会叠加生效。排查时要逐个检查，不能只看其中一个。
