EKS中ALB Ingress异常：React/Next.js应用内容返回404

在AWS EKS中已部署ALB Ingress Controller及相关服务，添加Ingress后ALB成功创建，但访问服务时返回404/400错误，本地运行服务镜像一切正常。

相关配置 #

Ingress资源配置 #

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: applications-ingress
  namespace: applications
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /mocktest
            pathType: Prefix
            backend:
              service:
                name: mocktest-frontend
                port:
                  number: 4000
          - path: /library-app
            pathType: Prefix
            backend:
              service:
                name: library-app
                port:
                  number: 3000

ALB Ingress Controller Helm发布配置（Flux） #

spec:
  releaseName: aws-load-balancer-controller
  chart:
    spec:
      chart: aws-load-balancer-controller
      version: 1.8.2
      sourceRef:
        kind: HelmRepository
        name: eks-charts
      interval: 1h
  values:
    clusterName: eks-project
    serviceAccount:
      create: false
      name: aws-load-balancer-controller
  interval: 1h

故障现象 #

访问示例路径（如http://k8s-applicat-applicat-3e293401b4-218248430.ap-south-1.elb.amazonaws.com/library-app）返回404错误，提示无法加载资源；React/Next.js应用均存在资源获取失败问题，部署nginx:latest服务也返回400错误。

1. 路径转发与应用路由匹配问题 #

这是前端应用通过Ingress子路径访问时最常见的问题：

• 应用基础路径配置缺失：React/Next.js默认以根路径/部署，当ALB将/library-app/xxx这类路径直接转发给后端服务时，应用内部找不到对应路由，导致404。需要在应用构建/配置中指定基础路径：
  • React：构建时添加环境变量PUBLIC_URL=/library-app（如PUBLIC_URL=/library-app npm run build）
  • Next.js：在next.config.js中配置basePath: '/library-app'
• Ingress路径转发规则问题：若不想修改应用配置，可通过ALB的路径重写注解将子路径转发到服务根路径。修改Ingress的annotations和paths：

  metadata:
    annotations:
      # 添加重写规则
      alb.ingress.kubernetes.io/rewrite-target: /$1
      # 其他注解保持不变
  spec:
    rules:
      - http:
          paths:
            - path: /mocktest(/|$)(.*)
              pathType: ImplementationSpecific
              backend:
                service:
                  name: mocktest-frontend
                  port:
                    number: 4000
            - path: /library-app(/|$)(.*)
              pathType: ImplementationSpecific
              backend:
                service:
                  name: library-app
                  port:
                    number: 3000
  

• Nginx测试服务的400问题：nginx默认期望根路径请求，直接转发/library-app会触发400，同样需要通过上述重写规则将路径转为/。

2. ALB目标组健康检查与状态验证 #

ALB只会将请求转发到健康检查通过的后端目标：

• 登录AWS控制台，找到对应ALB的目标组，查看：
  • 目标组内的EKS Pod IP是否处于健康状态
  • 健康检查路径是否正确：若应用的健康检查路径不是/，需在Ingress中添加注解alb.ingress.kubernetes.io/healthcheck-path: /your-health-path
  • 目标组的转发端口是否与服务端口（3000/4000）一致
• 若健康检查失败，检查Pod的健康状态：kubectl get pods -n applications，确认Pod是否正常运行且就绪。

3. ALB Ingress Controller配置与日志排查 #

• 查看Controller日志：检查Controller是否有错误或警告信息，比如权限不足、Ingress解析失败：

  kubectl logs -n kube-system deployment/aws-load-balancer-controller -f
  

• 验证IngressClass关联：确认集群中存在alb类型的IngressClass，且Controller已关联该类：

  kubectl get ingressclass
  

• Service Account权限验证：因为配置了serviceAccount.create: false，需确认aws-load-balancer-controller这个SA已绑定AmazonEKSLoadBalancerControllerPolicy权限，否则Controller无法正常创建/管理ALB资源。
• 版本兼容性：确认ALB Controller 1.8.2与EKS集群版本兼容（1.8.x支持EKS 1.21~1.24，若集群版本高于1.24需升级Controller）。

4. 集群内部服务连通性测试 #

确认服务本身在集群内可正常访问：

• 测试Service访问：在集群内启动一个测试Pod（如busybox），执行：

  kubectl run -it --rm busybox --image=busybox:1.36 -- sh
  # 访问服务
  curl http://library-app.applications.svc.cluster.local:3000
  curl http://mocktest-frontend.applications.svc.cluster.local:4000
  

• 检查Endpoints状态：确认服务已关联到可用的Pod端点：

  kubectl get endpoints library-app -n applications
  

  若Endpoints为空，检查Service的selector是否与Pod的labels匹配。

5. 安全组与网络配置检查 #

• ALB安全组：确认已允许80端口的入站流量（从0.0.0.0/0或指定IP段）
• 目标组安全组：确认Pod所在节点的安全组允许ALB安全组访问3000/4000端口
• VPC路由与NAT网关：若应用需要访问外部资源，确认集群VPC的路由配置正常，NAT网关工作正常。

内容的提问来源于stack exchange，提问作者GAJJAVARAPU SAI HARSHA