Lambda与同VPC内EC2网络连通性排查求助

这种明明过了Reachability Analyzer但实际请求超时的情况真的挺磨人的，我结合自己踩过的坑给你列几个排查方向，你可以挨个试试：

• 先确认EC2上的服务是否真的在正常监听
  登录EC2实例，用netstat -tulpn命令检查目标HTTPS端口（默认是443）的监听状态：

  • 要确保端口是监听在0.0.0.0或者EC2的内网IP上，要是只监听127.0.0.1，那Lambda肯定访问不到
  • 同时在EC2本地用curl -v https://localhost:你的端口测试服务本身能不能正常响应，排除服务自身的问题

• 再仔细核对安全组规则
  虽然你说两者共享同一个安全组，但还是要抠细节：

  • 入站规则里，有没有明确允许来自该安全组自身的HTTPS流量？有时候可能误设成了只允许特定IP段，而不是通过安全组引用授权
  • 出站规则也要确认：Lambda所在的安全组是否允许HTTPS（443端口）出站到EC2所在的内网IP范围，同子网默认路由是通的，但万一出站规则有限制呢？

• 检查Lambda的VPC配置细节

  • 去Lambda控制台的「配置」->「VPC」页面，确认它确实关联了正确的子网和安全组，有没有配置时选错的情况
  • 查看Lambda对应的弹性网络接口（ENI）状态：在EC2控制台的「网络接口」里找到Lambda的ENI，确认状态是「可用」，且已分配内网IP
  • 核对子网的路由表：同VPC同子网的话默认路由是通的，但还是要确认路由表里有没有拒绝流量的条目，或者有没有错误的路由指向

• 抓包排查（最直接的定位方式）
  在EC2上用tcpdump抓包，过滤Lambda的ENI IP和目标端口，比如：

  tcpdump -i eth0 host 你的Lambda_ENI_IP and port 443
  

  然后触发Lambda调用，观察抓包结果：

  • 如果没抓到请求包：说明网络路径确实有问题，回头再查安全组、路由表
  • 如果抓到了请求包但没看到EC2的回复：那大概率是EC2的服务没处理，或者本地防火墙（比如iptables）拦截了回复包

• 查看Lambda的日志和运行环境

  • 去CloudWatch Logs里看Lambda的执行日志，有没有更详细的错误信息？比如是「连接超时」还是「读取超时」，这能帮你缩小范围
  • 确认代码里用的是EC2的内网IP或者内网DNS名称，千万别用公网IP/域名，不然会绕去公网，超时是必然的
  • 检查EC2的负载状态：看CloudWatch指标里的CPU、内存使用率，要是实例负载拉满了，服务可能根本处理不过来请求

备注：内容来源于stack exchange，提问作者Gandalf