很多人第一次把服务部署到阿里云ECS上，都会碰到同一个情况：程序已经启动，公网却打不开。多数时候问题出在端口没有放行。下面结合几个实际场景，说一下ECS端口该怎么开，出了问题又怎么查。
先分清两道关口
外部请求要到达ECS上的服务，一般要过两道关。外层是阿里云的安全组，决定哪些流量能进入实例。里层是操作系统自带的防火墙，CentOS上常见的是firewalld，Ubuntu上常见的是ufw，老一些的系统也可能直接用iptables。两道都要放行，请求才能真正到达服务。
排查顺序可以固定下来：先确认服务在监听，再看安全组，最后查系统防火墙。只改了其中一处就以为解决了，是最常见的误判。
在控制台添加安全组规则
进入ECS管理控制台，打开实例详情页，在“安全组”选项卡里点击“配置规则”，就能看到规则列表。新增规则时，主要关注下面几个字段：
- 规则方向：对外提供服务的端口只需要配置入方向。出方向管的是实例主动访问外部的流量，一般不用动。
- 授权策略：选“允许”或“拒绝”。同一优先级下，拒绝规则会优先于允许规则，写了两条冲突的规则时要留意这一点。
- 优先级：数字越小优先级越高，取值范围是1到100。
- 协议类型：Web和SSH一般用TCP；DNS、部分游戏服务会用到UDP；ping测试走ICMP。
- 端口范围：单个端口直接填，比如80/80；连续端口用斜杠连接，比如8000/8080。
- 授权对象：填IP或网段。203.0.113.10/32只放行这一台机器，0.0.0.0/0则对所有地址开放，后者要谨慎使用。
规则保存后通常立即生效，不需要重启实例。但规则写错同样会立刻影响访问，所以修改前最好先记下原来的配置。
案例一：Nginx部署后80和443打不开
某个团队在ECS上装了Nginx，实例内用curl访问本机正常，浏览器访问公网IP却一直超时。他们先在实例里执行ss -tlnp，确认Nginx已经监听80端口，然后打开安全组，发现只放行了22端口，HTTP和HTTPS都没加。补上两条入方向规则，授权对象设为0.0.0.0/0，访问很快恢复。
这类情况的要点很简单：Web服务用的标准端口必须显式放行。之后如果要启用HTTPS，443也要一起开，并且在Nginx里配好证书。
案例二：数据库端口对公网开放
另一个项目把MySQL装在ECS上，为了远程连接方便，直接在安全组里把3306对0.0.0.0/0放开了。一周之后，日志里出现大量异常登录记录，数据库账号也被人尝试暴力破解。
数据库端口只应该对应用服务器的内网IP开放，或者只对运维人员固定的办公IP开放。确实需要远程管理时，优先走VPN或堡垒机。SSH的22端口和Windows远程桌面的3389端口也是同样道理，授权对象要收窄，并配合密钥登录或更严格的认证方式。
案例三：安全组已放行，服务还是不通
一位开发者在安全组里已经放行了8080，Java应用却仍然访问不了。检查后发现，系统里开启了firewalld，默认区域并没有包含8080。执行firewall-cmd –permanent –add-port=8080/tcp，再执行firewall-cmd –reload，问题就解决了。
这种情况的特点是，控制台看起来一切正常，外部访问却失败。排查时可以先在外部机器上用telnet或nc测试端口连通性，再逐层确认系统防火墙和服务本身的监听状态。
服务绑定在了哪里
有时安全组和防火墙都没问题，服务却只监听在127.0.0.1上。这样实例内部访问正常，外部连不进来。用ss -tlnp看一下监听地址，如果显示的是127.0.0.1:端口，就需要把应用配置里的监听地址改成0.0.0.0或具体的内网IP。
实际操作时的几点提醒
- 只开业务必需的端口，不要图省事全端口放行。
- 每条规则都写上备注，比如“订单服务接口”“运维办公网”，过段时间回看时才知道它为什么存在。
- 测试期间临时加的端口，用完及时删除，它们最容易被遗忘。
- 办公IP经常变动的团队，可以用安全组的地址簿统一维护，避免每条规则都要单独改。
- 生产环境改安全组前，先在测试实例上验证一遍，减少误操作导致的中断。
阿里云ECS端口本身并不难配，难的是分清两层防护各管什么，并在开放访问和控制风险之间找到平衡。遇到访问不通时，按“服务监听、安全组、系统防火墙”的顺序查下来，大多数问题都能较快定位。
