EKS环境Nginx Ingress代理Next.js返回404问题咨询

AI 小北

2026-9-1

问题定位

你的问题和网上流传的各类请求头注解方案没有任何关系，是配置逻辑和部署思路两个层面都存在错误：

第一，rewrite-target是Ingress级别的全局注解，你当前配置的/$3捕获组是专门适配前面file-api路径正则规则的，对/app开头的Next.js路径完全不适用。全局生效的重写规则会把所有发往Next.js的请求路径改写错乱，静态资源请求到达后端后路径不匹配，自然返回Next.js层的404。
第二，你写的configuration-snippet完全是负优化。Nginx Ingress会自动为每个后端生成标准的proxy_pass代理配置，你手动在snippet里定义的location /app块优先级高于自动生成的配置，这个块里没有配置后端转发规则，等于直接截胡了正常的代理逻辑。你注释里问的proxy_pass要不要加——只要你在snippet里写独立location块就必须加，但你根本没必要自己写这个块，里面列的所有proxy头参数在Ingress默认配置里都已经存在，重复配置反而可能引发冲突。
第三，子路径部署Next.js本身有硬性要求，不是光配Ingress就能正常运行。如果要把Next.js挂载在/app这类子路径下，必须在构建阶段就给Next.js配置basePath: '/app'，否则Next.js生成的页面、静态资源引用路径全是根路径开头，就算Ingress配得完全正确，浏览器加载资源时也会请求到错误路径，返回空白页。

修复方案

按优先级操作即可：

把不同后端的Ingress规则拆成独立的Ingress资源，不要把需要不同重写规则的服务塞在同一个Ingress里配置全局注解，避免规则串扰。
删掉所有自定义的configuration-snippet配置，不要手动写location块拦截默认代理逻辑。
调整Next.js配置：在项目的next.config.js中添加basePath: '/app'配置，重新构建镜像部署。这一步做完之后，Next.js本身就能正确识别/app前缀的请求，连重写规则都不需要额外配置，是稳定性最高的方案。
如果暂时不想重新构建Next.js镜像，就给Next.js的Ingress配置正确的正则路径和匹配的重写规则，不要复用file-api的捕获组，参考配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nextjs-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /app(/|$)(.*)
            pathType: Prefix
            backend:
              service:
                name: nextjs-service
                port:
                  number: 80

对应的file-api服务可以单独建一个Ingress，保留你原来的正则路径和rewrite-target: /$3配置即可，两个Ingress绑定同一个host不会产生冲突，Nginx Ingress会自动合并路由规则。

注意：如果不配置Next.js的basePath，就算重写规则写对了，页面里的前端路由跳转还是会丢失/app前缀，只是静态资源能临时加载成功，长期运行一定会出现路由异常，还是建议修改Next.js配置后重新构建。

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