AWS EC2实例无法连接远程GCP主机MongoDB实例的排查求助

针对你遇到的本地能正常连接但EC2实例超时的问题，我整理了几个常见的排查方向，你可以逐一验证：

• 确认EC2的实际出站IP是否正确加入GCP防火墙
  有些EC2实例如果部署在私有子网、通过NAT网关出站，其实际的公网出口IP是NAT网关的IP，而非EC2实例本身的公网IP。你可以在EC2上执行以下命令获取真实出站IP：

  curl ifconfig.me
  

  把这个IP和GCP防火墙规则里添加的IP对比，确保完全一致。

• 检查GCP防火墙规则的优先级与应用范围

  • 确认你的允许规则优先级高于任何拒绝类规则（GCP防火墙规则数字越小优先级越高），避免被高优先级的拒绝规则覆盖；
  • 检查规则是否正确应用到了MongoDB所在的GCP主机——如果规则是绑定特定网络标签的，要确保主机已经添加了对应标签。

• 验证GCP主机的本地防火墙设置
  云平台防火墙放行后，主机自身的防火墙（如ufw或iptables）可能仍会拦截流量。在GCP主机上执行以下命令检查：

  # 检查ufw状态
  sudo ufw status
  # 检查iptables规则
  sudo iptables -L -n
  

  确保27017端口允许来自EC2出站IP的访问。

• 检查EC2所在VPC的网络ACL配置
  VPC网络ACL是无状态的，即使EC2出站规则允许所有流量，入站规则也需要允许TCP连接的响应流量（即ESTABLISHED, RELATED状态的数据包）。你可以临时将网络ACL的入站规则设置为允许所有TCP流量，测试是否能连接，以此排除ACL的影响。

• 用路由追踪定位网络瓶颈
  在EC2上执行路由追踪命令，查看数据包的传输路径，定位卡在哪个环节：

  # 使用traceroute
  traceroute 35.198.56.213
  # 或者更详细的mtr（如果已安装）
  mtr 35.198.56.213
  

  如果数据包卡在AWS内部，可能是AWS侧的路由问题；如果卡在跨云节点，可能需要联系云服务商确认网络链路状态。

• 再次确认MongoDB的监听状态
  虽然你已经设置了bindIp: 0.0.0.0，但可以在GCP主机上再验证一下MongoDB是否真的在监听所有网卡的27017端口：

  sudo netstat -tulpn | grep 27017
  

  输出应该显示0.0.0.0:27017或:::27017，确认服务正常监听。

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