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

问题背景

在使用 Apache APISIX 作为 Kubernetes Ingress 控制器时，开发人员可能会遇到一个常见的重定向问题：当后端服务返回 302 重定向响应时，目标 URL 的端口会被意外地从标准的 443 端口修改为 9443 端口，导致重定向失败。

问题分析

这种现象通常是由于以下几个技术因素造成的：

1. X-Forwarded-Port 头部处理：APISIX 在转发请求时会添加 X-Forwarded-Port 头部，而后端服务可能会基于这个头部来构造重定向 URL。

2. 容器端口限制：默认情况下，Kubernetes 中的容器无法直接绑定到 1024 以下的特权端口（如 443），这导致 APISIX 默认使用非标准端口（如 9443）。

3. TLS 终止配置：当 APISIX 作为 Ingress 控制器时，通常会在边缘节点处理 TLS 终止，而后端服务可能不了解实际的客户端访问端口。

解决方案

方案一：修改容器端口配置（推荐）

这是最彻底的解决方案，通过以下步骤让 APISIX 直接监听 443 端口：

1. 修改 Helm Chart 配置：

apisix:
  ssl:
    enabled: true
    containerPort: 443

2. 添加 Pod 安全上下文配置：

podSecurityContext:
  sysctls:
    - name: net.ipv4.ip_unprivileged_port_start
      value: "1"

这个配置做了两件事：

• 将 APISIX 容器的 SSL 端口设置为标准的 443 端口
• 通过修改内核参数允许容器绑定特权端口

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

如果不方便修改端口配置，可以使用 serverless-pre-function 插件来强制设置 X-Forwarded-Port 头部：

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

技术原理深入

1. 端口重写机制： APISIX 作为反向代理时，会根据实际监听的端口来重写 Location 头部。当它监听 9443 端口时，会自动将重定向响应中的端口改为 9443。

2. Linux 端口安全： Linux 系统默认禁止非 root 用户绑定 1024 以下的端口。通过设置 net.ipv4.ip_unprivileged_port_start=1，我们降低了这个限制，使容器可以绑定到 443 端口。

3. 生产环境考量： 虽然方案二也能解决问题，但在生产环境中更推荐方案一，因为：

• 保持使用标准端口（443）更符合常规配置
• 减少不必要的插件处理开销
• 避免潜在的头部修改导致的兼容性问题

最佳实践建议

1. 在 Helm 安装时就直接配置使用 443 端口，避免后续出现兼容性问题。

2. 对于已有环境，建议在维护窗口期进行端口迁移，确保服务连续性。

3. 监控系统日志，确保端口修改后没有出现权限相关问题。

4. 考虑在 Ingress 配置中添加适当的注解来明确指定外部端口。

通过以上解决方案，可以确保 APISIX 正确处理来自后端服务的重定向响应，保持用户体验的一致性和服务的可靠性。