AWS双EC2实例配置Network ACL解决curl连接拒绝问题

先明确关键信息 #

在修改Network ACL之前，先确认两个核心细节：

• Network ACL是子网级配置，而非绑定单个EC2实例，需定位两台EC2各自所属的子网
• 确认Nginx Docker容器映射的主机端口：在目标EC2上执行docker ps，查看类似0.0.0.0:80->80/tcp的输出，前面的80就是主机需开放的端口；若自定义了端口（如8080），则以实际映射值为准

1. 配置发起请求的EC2所在子网的出站ACL规则 #

让发起方EC2能向目标实例发送请求：

• 规则优先级：设置为小于默认拒绝（*）的数值（比如100，数值越小优先级越高）
• 类型：若端口为80则选HTTP，其他端口选「自定义TCP」
• 协议：TCP（编号6）
• 端口范围：填写Nginx映射的主机端口（如80）
• 目标：填写目标EC2的私有IP，或目标子网的CIDR（若同一VPC内有多台实例）
• 动作：允许

2. 配置目标EC2所在子网的入站ACL规则 #

让目标实例能接收发起方的请求：

• 规则优先级：同样设为100左右（优先级高于默认拒绝）
• 类型：对应端口选HTTP或自定义TCP
• 协议：TCP（6）
• 端口范围：填写Nginx映射的主机端口
• 源：填写发起方EC2的私有IP，或发起方所在子网的CIDR
• 动作：允许

3. 必须配置返回流量的规则（ACL是无状态的！） #

AWS Network ACL为无状态配置，发出的请求不会自动放行返回流量，需手动添加规则：

• 目标EC2所在子网的出站规则：允许TCP临时端口范围（通常为1024-65535），目标设为发起方EC2的IP/子网，动作为允许
• 发起方EC2所在子网的入站规则：允许TCP临时端口范围（1024-65535），源设为目标EC2的IP/子网，动作为允许

提示：如果使用的是默认Network ACL，默认允许所有入站出站流量，此时问题大概率不在ACL，需排查安全组或Docker配置。

额外排查点（别仅局限于ACL） #

• 检查目标EC2的安全组：必须允许来自发起方IP/子网的对应端口访问，安全组为实例级配置，是此类问题的高频诱因
• 目标EC2本地测试：执行curl localhost:80（替换为你的映射端口），确认Nginx服务本身正常运行
• 端口监听检查：在目标EC2上执行netstat -tulpn | grep 80，确认主机端口已被Docker监听（输出需包含0.0.0.0:80或对应端口）

内容的提问来源于stack exchange，提问作者Emir Khan