接手第三方AWS架构后操作引发ELB目标组内原有EC2实例不健康及502错误排查求助

先给你梳理几个不用SSH登录就能推进的排查路径，帮你快速定位问题并恢复原有应用：

1. 优先核查目标组健康检查配置是否被误改 #

目标组的健康检查规则是判定实例状态的核心，很可能在创建新目标组的操作中不小心修改了原有配置：

• 登录AWS控制台找到原有负载均衡器关联的目标组，重点核对健康检查路径（比如原有是不是/health或者根路径/）、监听端口（是否和Node/React应用的运行端口匹配）、协议（HTTP/HTTPS是否和应用一致）、超时/重试阈值这些参数
• 如果你的AWS账号开启了AWS Config，可以直接查该目标组的历史变更记录，确认是否有参数被意外篡改（比如健康检查路径被改成了新应用的路径，导致原有实例返回非2xx/3xx状态）

2. 从AWS层面排查实例与网络的基础状态 #

即使没SSH密钥，也能通过AWS自带工具获取关键信息：

• 查看EC2实例的状态检查结果：在EC2实例详情页，看「系统状态检查」和「实例状态检查」是否正常。如果是系统状态检查失败，大概率是AWS底层硬件问题，尝试停止再启动实例（注意如果用的是临时公网IP，停止后会释放，记得绑定弹性IP）；如果是实例状态检查失败，说明实例内部系统或应用出问题，继续往下排查
• 验证安全组与NACL规则：确认原有EC2实例的安全组是否允许负载均衡器所在安全组访问应用端口（健康检查流量来自ELB的安全组，不是0.0.0.0/0）；同时检查VPC的网络ACL，是否有规则阻断了ELB到EC2的流量
• 查看VPC流量日志：如果你的VPC开启了流量日志，直接检索目标组到EC2实例的流量记录，看是否有被拒绝的数据包

3. 利用CloudWatch与EC2系统日志排查内部问题 #

很多时候不用登录实例也能拿到内部报错：

• 检查CloudWatch日志：如果原有EC2配置过CloudWatch Agent，把应用日志（Node/React的启动日志、错误日志）或系统日志推送到了CloudWatch，直接去对应日志组找最近的报错，比如是否有OOM（内存耗尽）、磁盘满了、Node进程崩溃的提示
• 查看EC2系统日志与控制台输出：在EC2实例详情页，点击「获取系统日志」和「获取控制台输出」，这里会记录实例启动时的系统信息、服务启动失败的提示，比如Nginx/Apache是否没正常启动、端口被占用等

4. 应急恢复方案（快速恢复业务） #

如果以上排查暂时没进展，先优先恢复业务：

• 用原有AMI重新创建一台EC2实例，一定要创建并保存新的密钥对，启动后临时在安全组里加一条自己IP的入站规则，直接访问实例IP验证应用是否能正常运行
• 确认新实例应用正常后，把它加入原有目标组，替换掉不健康的旧实例，先让业务恢复
• 之后再慢慢排查旧实例不健康的根本原因，避免再次出现

另外提醒下：后续操作AWS资源时，尽量用最小权限的IAM角色，避免误改原有资源；建议开启AWS Config记录所有资源的变更历史，方便回溯操作；重要实例的密钥对一定要备份好。

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