Strapi项目在Azure部署中遇到的401未授权错误分析与解决

在Strapi项目部署到Azure应用服务的过程中，开发团队遇到了一个看似随机出现的401未授权错误。这个问题表现为前端React应用通过Axios调用Strapi API时，有时能正常返回200状态码，有时却会返回401未授权错误，并伴随CORS策略错误提示。

问题现象

当问题发生时，控制台会显示CORS错误信息，提示请求的资源上不存在'Access-Control-Allow-Origin'头部。值得注意的是，预检OPTIONS请求始终返回200 OK状态码，这表明CORS配置本身可能不是问题的根源。

深入排查

开发团队首先检查了Strapi的CORS配置，尝试了默认配置和自定义配置两种方案。自定义配置中明确指定了允许的源、方法和头部信息，包括必要的Authorization头部。然而，问题依然存在，这表明问题可能不在Strapi的CORS设置上。

进一步分析请求和响应头部的差异发现了一个关键线索：在401错误的响应中，Set-Cookie头部包含"x-ms-routing-name=testing"，而成功请求的响应中则是"x-ms-routing-name=self"。这表明请求被意外路由到了Azure的测试部署槽(testing slot)，而非预期的生产槽(production slot)。

Azure部署槽机制解析

Azure应用服务的部署槽功能允许开发团队在不影响生产环境的情况下测试新版本。每个部署槽本质上是一个独立的应用实例，可以有自己的配置和环境变量。默认情况下，Azure会自动将一定比例的流量路由到非生产槽，这可能导致部分请求被发送到错误的实例。

解决方案

要解决这个问题，需要确保所有生产流量都路由到正确的生产槽：

1. 在Azure门户中导航到应用服务的部署槽配置
2. 将生产槽(production)的流量分配设置为100%
3. 将测试槽(testing)的流量分配设置为0%

这样配置后，所有请求都会被正确路由到生产环境，避免了随机401错误的发生。

经验总结

这个案例展示了云环境部署中常见的一个陷阱：看似随机的API错误可能源于基础设施的配置问题而非应用代码本身。当遇到类似问题时，建议开发团队：

1. 仔细比较成功和失败请求的完整请求/响应周期
2. 检查云服务提供商特有的路由和流量分配机制
3. 验证环境变量和配置在不同部署槽中的一致性

通过系统性的排查方法，可以快速定位并解决这类隐蔽的基础设施问题，确保应用的稳定运行。