从Cloud9访问private subnet内无public IP的EC2失败，求排查原因

场景说明 #

• Private Subnet内的EC2实例：私有IP为172.31.50.95，无公网IP
• Public Subnet内的Cloud9实例尝试访问该EC2，执行命令后卡在连接阶段：

  $ wget 172.31.50.95
  --2024-09-09 15:02:23--  http://172.31.50.95/
  Connecting to 172.31.50.95:80... 
  

• 已知信息：EC2安全组已开放80端口允许0.0.0.0/0访问，HTTP服务本地运行正常

核心疑惑解答 #

私有IP并非只能在同一子网内使用——同一VPC下的所有子网，只要路由配置正确，都可以通过私有IP互相通信。问题大概率不在私有IP的跨子网有效性，而是路由、网络ACL或其他配置问题。

具体排查步骤 #

• 检查子网路由表的本地路由

  • Public Subnet路由表：必须包含指向VPC整体CIDR（比如172.31.0.0/16，需匹配你的VPC实际网段）的local路由，这条路由负责VPC内私有IP流量的子网间转发，缺失则Cloud9无法将流量发往Private Subnet的EC2
  • Private Subnet路由表：同样需要包含上述local路由，确保EC2能接收并回应来自Public Subnet的流量

• 检查网络ACL配置
  网络ACL是子网级防火墙，默认允许所有进出，但如果有自定义规则，需确认：

  • 入方向规则：允许来自Public Subnet CIDR的80端口流量
  • 出方向规则：允许发往Public Subnet CIDR的任意端口流量（TCP连接需要回应包，出方向不能限制）

• 确认EC2的服务监听范围
  在EC2上执行以下命令，检查HTTP服务的监听地址：

  netstat -tulpn | grep :80
  

  确保服务监听在0.0.0.0:80或172.31.50.95:80，如果仅监听127.0.0.1:80，则仅本地能访问，跨机器无法连接

• 测试基础连通性
  先跳过HTTP，用基础工具测试网络连通性：

  • 执行ping 172.31.50.95：如果不通，说明网络层（路由、ACL、安全组ICMP规则）存在问题
  • 执行telnet 172.31.50.95 80：如果能连通但wget失败，再排查HTTP服务的具体配置（比如虚拟主机、路径映射等）

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