使用PowerShell通过Kudu ZipDeploy部署到Azure后API访问出现401错误

我来帮你定位这个问题——毕竟从Visual Studio直接部署正常，换成Bamboo+Kudu ZipDeploy就出401，大概率是部署流程中某些配置没同步或者关键细节遗漏了。下面是几个常见的排查方向：

• 检查Azure App Service的身份验证配置
  之前用VS部署时，可能自动帮你配置了App Service的「Authentication/Authorization」功能（比如开启匿名访问、绑定Azure AD等），但Kudu的ZipDeploy不会自动同步这些平台级配置。你可以登录Azure Portal，找到你的App Service，进入「Authentication」选项卡：

  • 确认是否开启了正确的身份验证模式，如果你的API原本允许匿名访问，现在是不是被设置成「需要身份验证」了？
  • 如果用的是Azure AD或其他身份提供者，检查租户ID、应用ID等参数是否和之前VS部署时一致。

• 核对发布包的配置文件与环境变量
  VS发布时会根据你选择的发布配置（Debug/Release）自动替换appsettings.json或appsettings.Production.json里的参数，比如JWT密钥、身份验证的Issuer/Audience等。你需要确认：

  • PowerShell脚本打包的是不是Release环境的发布产物？有没有错误打包了Debug版本的配置？
  • 登录Azure Portal的App Service「Configuration」选项卡，检查应用设置（环境变量）里的身份验证相关参数是否和之前VS部署的一致——有时候ZipDeploy不会覆盖平台级的环境变量，但如果之前的配置是VS自动设置的，可能需要手动同步。

• 查看Kudu与App Service的日志
  部署成功不代表配置没问题，日志能帮你找到线索：

  • 访问Kudu控制台（https://<你的应用名>.scm.azurewebsites.net/），进入「Deployment Options」查看对应部署记录的详细日志，看有没有配置文件替换失败、权限相关的警告信息。
  • 打开App Service的「Log Stream」或者「Application Logs」，尝试访问API，查看具体的错误日志——比如是JWT令牌验证失败，还是匿名访问被中间件拒绝，这些细节能直接指向问题根源。

• 检查ASP.NET Core中间件配置
  确认你的Startup.cs里身份验证相关的中间件配置是否正确，尤其是顺序：

  // 注意顺序：先认证，再授权
  app.UseAuthentication();
  app.UseAuthorization();
  

  另外，检查是否在Production环境下有额外的权限验证逻辑——比如VS部署时可能用了特定的环境变量开关，而Bamboo部署后这个变量没设置，导致中间件强制要求身份验证。

• 对比VS发布包与Bamboo打包内容
  把VS发布生成的本地文件夹和Bamboo打包的Zip文件内容做对比，看是否有关键文件缺失：

  • 比如web.config（如果是IIS托管）里的ASP.NET Core模块配置是否正确，有没有权限相关的设置差异；
  • 有没有漏掉VS发布时自动生成的身份验证相关配置文件。

内容的提问来源于stack exchange，提问作者whiskytangofoxtrot