咱们一步步拆解这个场景下的实际路由行为，核心逻辑是NGINX Ingress Controller会把针对同一Host的多个Ingress资源规则合并到同一个NGINX Server配置块中，最终遵循「最长路径优先匹配」原则，再结合注解的作用来具体生效：

1. 明确路径的路由优先级 #

对于/identity、/idp、/passport这类具体路径：

• 它们会优先匹配第一个Ingress（{{ $fullName }}-stateful）里的对应规则——因为这些路径比第二个Ingress中的/更长、更具体，符合NGINX的路径匹配优先级。
• 实际访问效果：
  • 访问/identity → 转发到oxtrust:8080
  • 访问/idp → 转发到oxshibboleth:8080
  • 访问/passport → 转发到oxpassport:8090

2. 根路径/的特殊处理 #

这里有两个关键配置共同作用：

（1）app-root注解的重定向逻辑 #

两个Ingress都配置了nginx.ingress.kubernetes.io/app-root: "/identity"，这个注解会在合并后的NGINX配置中添加一条全局重定向规则：

return 301 $scheme://$host/identity;

当用户访问根路径/时，会直接被NGINX以301（永久重定向）跳转到/identity，随后就会匹配上面提到的/identity路径规则，最终转发到oxtrust:8080。

（2）第二个Ingress中path: /的实际作用 #

这个规则并不会处理根路径/的请求（因为被app-root的重定向提前拦截了），它的实际作用是兜底匹配所有未被其他具体路径覆盖的请求：比如访问/random、/test这类没有在第一个Ingress中定义的路径时，会匹配/这个兜底规则，转发到oxtrust:8080。

3. 同类型注解的合并逻辑 #

两个Ingress都配置了部分相同的注解（比如affinity: cookie），对于这类针对整个Server的注解，NGINX Ingress Controller通常会取最后被处理的Ingress的配置（或进行覆盖合并，具体取决于Controller版本）。不过在你的场景中，两个Ingress的app-root注解值完全一致，所以不会产生冲突，最终只会生成一条统一的重定向规则。

另外第一个Ingress中的nginx.org/ssl-services: "oxtrust"注解，是指定仅对oxtrust服务启用后端SSL代理（如果你的后端服务是HTTPS协议的话），其他服务（oxshibboleth、oxpassport）会默认用HTTP转发，这个配置和路由逻辑不冲突。

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