这个问题的核心原因很明确：你的Ingress配置用了rewrite-target: /$1，把请求路径里的/srv1/前缀剥离后转发给后端服务。后端服务收到的请求路径是/page1.aspx，当它发起服务端重定向时，只会基于自己感知到的路径生成跳转URL，自然就漏掉了/srv1/前缀，导致跳转到https://xyz.example.com/page2.aspx；而客户端HTML链接是基于浏览器地址栏里的完整路径（带/srv1/）做相对跳转，所以能正常工作。

下面给你几种可行的解决方案，按推荐程度排序：

方案1：通过Ingress注解修改后端重定向的Location头（无需修改服务代码） #

Nginx Ingress允许我们通过configuration-snippet注解添加自定义Nginx配置，拦截后端返回的重定向响应，自动给Location头加上对应的前缀。

修改你的Ingress YAML，针对每个服务路径添加对应的重定向处理：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ds1-ingress
  namespace: ds1
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/configuration-snippet: |
      # 针对srv1的重定向处理
      if ($request_uri ~* ^/srv1/.*) {
        proxy_redirect ~^/(.*)$ /srv1/$1;
      }
      # 针对srv2的重定向处理
      if ($request_uri ~* ^/srv2/.*) {
        proxy_redirect ~^/(.*)$ /srv2/$1;
      }
spec:
  tls:
  - hosts:
    - xyz.example.com
    secretName: tls-secret
  rules:
  - host: xyz.example.com
    http:
      paths:
      - backend:
          serviceName: srv1
          servicePort: 80
        path: /srv1/(.*)
      - backend:
          serviceName: srv2
          servicePort: 80
        path: /srv2/(.*) # 这里建议把*改成(.*)保持规则一致性

这个方案的好处是完全不需要修改后端服务的代码或配置，所有逻辑都在Ingress层处理，对你测试的三种语言服务都适用。

方案2：传递X-Forwarded-Prefix头，让后端服务感知前缀 #

另一种思路是让后端服务知道它是被部署在/srv1前缀下的，这样服务端生成重定向时会自动加上这个前缀。我们可以通过Ingress添加X-Forwarded-Prefix请求头，然后让后端框架识别这个头。

第一步：修改Ingress配置添加请求头 #

metadata:
  annotations:
    # ...其他注解
    nginx.ingress.kubernetes.io/configuration-snippet: |
      set $prefix "";
      if ($request_uri ~* ^/srv1/.*) {
        set $prefix "/srv1";
      }
      if ($request_uri ~* ^/srv2/.*) {
        set $prefix "/srv2";
      }
      proxy_set_header X-Forwarded-Prefix $prefix;

第二步：配置后端服务识别前缀 #

不同语言的框架配置方式不同，给你举几个对应你测试场景的例子：

ASP.NET Core

在Startup.cs中配置转发头选项，让应用识别X-Forwarded-Prefix：

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders = 
            ForwardedHeaders.XForwardedFor | 
            ForwardedHeaders.XForwardedProto | 
            ForwardedHeaders.XForwardedHost;
        // 允许来自Nginx Ingress的转发头
        options.KnownNetworks.Clear();
        options.KnownProxies.Clear();
    });
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // 必须在其他中间件之前调用
    app.UseForwardedHeaders();
    
    // ...其他中间件配置（比如UseRouting、UseEndpoints等）
}

Python Flask

用before_request钩子处理前缀，确保重定向URL包含前缀：

from flask import Flask, request, redirect, url_for

app = Flask(__name__)

@app.before_request
def handle_prefix():
    prefix = request.headers.get('X-Forwarded-Prefix', '')
    if prefix and not request.path.startswith(prefix):
        request.path = prefix + request.path

# 重定向示例
@app.route('/page1.aspx')
def page1():
    # url_for生成的URL会自动带上前缀
    return redirect(url_for('page2'))

@app.route('/page2.aspx')
def page2():
    return "Page 2"

Ruby on Rails

添加中间件来处理前缀：

module YourApp
  class Application < Rails::Application
    # ...其他配置
    config.middleware.insert_before 0, Rack::Rewrite do
      rewrite %r{^/srv1(.*)}, '$1'
    end
  end
end

这个方案更符合HTTP规范，后端服务能正确感知自己的部署上下文，但需要修改服务代码或配置。

方案3：调整Ingress路径规则（不推荐） #

你也可以尝试去掉rewrite-target，让后端服务直接处理带/srv1前缀的请求，比如：

paths:
- backend:
    serviceName: srv1
    servicePort: 80
  path: /srv1/

但这种方式需要后端服务本身配置为监听/srv1路径下的请求，否则会返回404，灵活性较差，除非你能控制所有后端服务的部署配置，否则不推荐。

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