Apache APISIX 独立模式下正则路由重写失效问题解析

在使用Apache APISIX进行API网关配置时，开发者可能会遇到一个典型问题：在独立部署模式下，通过配置文件设置的regex_uri规则未能按预期重写请求路径。本文将深入分析该问题的成因，并提供完整的解决方案。

问题现象重现

当开发者采用Docker容器部署APISIX独立模式时，常见会编写如下配置：

routes:
  - id: sub
    uri: /api/*
    plugin_config_id: sub
    upstream:
      nodes:
        "host.docker.internal:3000": 1
    plugins:
      proxy-rewrite:
        regex_uri: ["^/api/(.*)", "/$1"]

预期行为是访问/api/sub-path时重定向到上游服务的/sub-path，但实际请求却被代理到了根路径/。

根本原因分析

该问题的核心在于独立模式下的配置加载机制。虽然通过环境变量APISIX_STAND_ALONE=true启用了独立模式，但缺少关键配置导致：

1. 默认配置缺陷：APISIX默认的config.yaml未显式声明独立模式配置，系统仍会尝试连接etcd服务
2. 配置加载优先级：当etcd连接失败时，通过文件配置的路由规则可能无法正确加载插件配置
3. 运行模式混淆：未明确定义数据平面角色，导致配置解析行为不一致

完整解决方案

关键配置修正

需要在conf/config.yaml中明确声明部署模式：

deployment:
  role: data_plane
  role_data_plane:
    config_provider: yaml

配置验证步骤

1. 检查容器日志：通过docker logs -f apache-apisix确认无etcd连接尝试
2. 测试路由规则：使用curl验证路径重写是否生效：

curl -v "http://localhost:9080/api/sub-path"

3. 配置热加载：修改配置后无需重启服务，APISIX会自动检测文件变化

技术原理延伸

APISIX的独立模式设计体现了以下架构特点：

1. 配置分离：明确区分控制平面和数据平面的配置职责
2. 文件热加载：采用inotify机制监控配置文件变更
3. 插件执行顺序：proxy-rewrite插件在ACCESS阶段执行路由重写

建议开发者在生产环境中注意：

• 对于复杂路由规则，建议先在控制台通过API测试
• 定期检查配置文件的语法有效性
• 监控插件执行日志以确认规则生效

通过正确理解APISIX的运行机制，可以充分发挥其高性能路由和插件系统的优势。