Apache APISIX中处理302重定向端口异常的解决方案

问题背景

在使用Apache APISIX作为Ingress控制器时，当后端服务返回302重定向响应时，经常会出现端口被意外修改的情况。具体表现为：用户通过HTTPS(443端口)访问资源时，后端返回的重定向响应会被APISIX自动修改为9443端口，导致重定向失败。

问题分析

这种现象的根本原因在于APISIX默认监听的SSL端口是9443，而后端服务在生成重定向URL时，会根据X-Forwarded-Port头信息来决定目标端口。当APISIX作为反向代理时，如果没有正确传递原始端口信息，后端服务就会使用APISIX的监听端口(9443)来构造重定向URL。

解决方案

方案一：修改APISIX监听端口

最直接的解决方案是将APISIX的SSL监听端口改为标准的443端口。在Helm部署环境下，可以通过修改values.yaml配置文件实现：

apisix:
  ssl:
    enabled: true
    containerPort: 443
    ...
podSecurityContext:
  sysctls:
    - name: net.ipv4.ip_unprivileged_port_start
      value: "1"

关键配置说明：

1. containerPort: 443：将APISIX容器的SSL端口改为443
2. sysctls配置：允许容器使用特权端口(1-1024)，默认情况下Kubernetes出于安全考虑会禁止容器使用这些端口

方案二：使用插件修改请求头

另一种解决方案是使用APISIX的serverless-pre-function插件，在请求到达后端前强制设置X-Forwarded-Port头为443：

plugins:
  - name: serverless-pre-function
    config:
      phase: rewrite
      functions:
        - "return function(conf, ctx)
            core.request.set_header(ctx, 'X-Forwarded-Port', '443')
          end"

这种方法虽然可行，但不够优雅，且需要在每个路由上配置，维护成本较高。

最佳实践建议

对于生产环境，推荐采用第一种方案，即将APISIX直接监听443端口。这种方案有以下优势：

1. 符合常规的HTTPS服务标准配置
2. 无需额外的插件配置
3. 减少请求处理链路的复杂度
4. 避免潜在的头部修改带来的副作用

同时，这种配置方式也更符合Kubernetes Ingress控制器的常规使用场景，使得APISIX的行为与其他Ingress控制器保持一致。

总结