DigitalOcean K8s NGINX Ingress暴露NodeJS服务502 Bad Gateway

从你贴的NGINX Ingress报错来看，根本故障点是Ingress控制器无法和目标Pod的3000端口建立TCP连接，按照排查优先级从高到低依次处理：

• 最高频原因：Pod内NodeJS应用的监听地址配置错误
  很多NodeJS项目启动时默认会把服务绑定到127.0.0.1回环地址，这种配置下只有Pod内部的进程能访问3000端口，集群内其他组件（包括Ingress控制器）发来的跨Pod请求会直接被拒绝，完全对应你现在遇到的连接被拒报错。
  验证操作：进入日志里提到的IP为10.244.0.112的Pod，执行ss -tulnp | grep 3000查看端口监听状态，只要返回的监听地址不是0.0.0.0或Pod的实际IP，就需要修改应用启动配置，强制绑定到0.0.0.0后重启Pod。
• 次高频原因：Service端点配置不匹配
  执行kubectl get endpoints service-api -n default，确认返回的后端条目里，端口确实对应3000。如果Service配置的targetPort和Pod实际暴露的端口不一致，哪怕Ingress已经拿到了Pod IP，发出去的流量也会被拒绝。
• 易遗漏原因：集群网络策略拦截
  如果集群中配置了默认拒绝入站的NetworkPolicy，没有放行Ingress控制器Pod到应用Pod 3000端口的流量，也会直接触发TCP连接被拒的报错。
• 配置冲突问题：DigitalOcean负载均衡注解逻辑矛盾
  你当前的Ingress注解里同时开了两类互斥的TLS处理逻辑：

  一边配置了cert-manager自动签发证书、由Ingress控制器负责对外提供HTTPS服务；另一边又加了service.beta.kubernetes.io/do-loadbalancer-tls-passthrough: "true"注解，要求负载均衡把加密TLS流量直接透传到后端，完全不做TLS终止。
  这种叠加配置很容易引发流量异常。如果你的后端NodeJS应用没有自行处理TLS加密的逻辑，直接删掉上面这行TLS透传的注解，走标准的“负载均衡转明文HTTP到Ingress→Ingress加载证书做HTTPS终止→转明文HTTP到后端3000端口”的链路即可。

• 基础状态校验：确认应用本身正常运行
  执行kubectl describe pod <对应Pod名称> -n default、kubectl logs <对应Pod名称> -n default，确认Pod内的NodeJS进程没有崩溃、没有出现端口占用类的启动失败问题。

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