Higress项目中Azure OpenAI API端点健康检查401问题的分析与解决

问题背景

在使用Higress网关对接Azure OpenAI API时，开发人员发现当配置了failover功能后，健康检查会返回401错误，提示"Access denied due to invalid subscription key or wrong API endpoint"。而关闭failover配置后，API访问则恢复正常。这一问题影响了通过Higress实现模型故障转移的能力。

问题现象

当启用健康检查配置时，发送到Azure OpenAI端点的请求会直接返回401错误。从日志中可以观察到以下关键信息：

1. 健康检查请求似乎没有携带正确的API密钥
2. 错误信息明确指出是订阅密钥无效或API端点错误
3. 关闭failover配置后，相同的请求可以正常工作

问题分析

经过深入排查，发现问题的根源在于健康检查机制对多模型供应商场景的处理不够完善。具体表现为：

1. 令牌与端点不匹配：当配置了多个模型供应商（如azure-openai-01和azure-openai-02）时，健康检查可能会错误地将一个供应商的API令牌用于另一个供应商的端点，导致认证失败。

2. 令牌丢失问题：在某些情况下，failover配置中的apitoken会意外变为空值，这直接导致了401错误的产生。

3. 健康检查机制缺陷：当前的实现仅通过apitoken来标识模型供应商，而没有考虑不同供应商可能具有完全不同的API主机地址、路径和认证方式。

解决方案

针对上述问题，建议从以下几个方面进行改进：

1. 完善模型供应商标识：不应仅依赖API令牌来标识模型供应商，而应该建立一个包含主机地址、路径和令牌的完整供应商配置模型。

2. 加强健康检查逻辑：确保健康检查请求总是使用与目标端点匹配的正确API令牌，避免跨供应商的令牌混用。

3. 增加错误处理机制：对于令牌丢失或无效的情况，应该有明确的错误处理和恢复机制，而不是简单地返回401错误。

4. 日志增强：在调试日志中明确记录健康检查使用的具体配置，包括目标端点和使用的令牌，便于问题排查。

实施建议

对于遇到类似问题的用户，可以采取以下临时解决方案：

1. 暂时关闭failover功能，等待官方修复
2. 如果必须使用failover，确保只配置单个模型供应商
3. 密切监控日志，及时发现并处理令牌丢失的情况

总结

Higress作为一款功能强大的API网关，在处理复杂的多云供应商场景时需要特别注意配置的一致性和正确性。本次Azure OpenAI API的401错误问题揭示了在多供应商环境下健康检查机制的不足，也为网关的健壮性改进提供了宝贵经验。开发团队已经确认了这一问题，并计划在后续版本中修复。