所有Web应用无法访问Kudu（scm）报403错误，应用运行正常且已开启两步验证

这种情况我之前碰到过好几次，给你几个亲测有效的排查方向，按顺序试应该能解决：

• 先确认Kudu服务本身的状态
  主应用正常不代表Kudu没出问题。你可以直接在Azure门户的应用服务页面，找到「开发工具」->「高级工具」，点击「Go」跳转Kudu。如果还是报错，试试手动重启Kudu：进入Kudu的「Process Explorer」，找到scm.exe进程右键「Kill Process」，等个几秒它会自动重启，之后再刷新页面试试。

• 两步验证带来的认证坑
  开启两步验证后，直接用微软账户密码登Kudu肯定会失败，因为缺了验证因子。这里有两个靠谱的解决办法：

  1. 去你的微软账户设置里生成一个应用密码，专门用来登录这类不支持两步验证的服务，用这个密码代替普通密码登Kudu就行。
  2. 用发布配置文件里的令牌登录：在Azure门户应用服务的「概述」里下载发布配置文件，打开xml文件找到userPWD字段，这个是带权限的令牌，搭配userName里的内容就能直接登录Kudu，不用管两步验证。

• 检查IP访问限制是否波及Kudu
  很多人给主应用加了IP访问限制，但忘了Kudu（scm站点）也有独立的限制规则。去应用服务的「网络」->「访问限制」，切换到「SCM站点」的选项卡，看看是不是你的访问IP被挡了，要么把IP加进允许列表，要么暂时关闭限制测试下能不能访问。

• 排查应用服务计划的资源瓶颈
  如果应用服务计划的CPU、内存跑满了，也会导致Kudu无法响应。去应用服务计划的「指标」页面看看资源使用率，要是过高的话，要么升级计划层级，要么重启下应用服务计划试试。

• 终极手段：重置Kudu配置
  要是上面的方法都没用，试试用Azure CLI重置Kudu的配置：

  az webapp config set --name <你的应用名称> --resource-group <你的资源组名称> --use-32bit-worker-process false
  

  如果本来就是32位模式，就改成true再改回false，这个操作会触发Kudu的配置重置，大概率能解决一些奇怪的状态问题。

小提示：如果有很多应用需要处理，可以用Azure CLI的批量命令来操作，省得一个个手动改。

内容的提问来源于stack exchange，提问作者Sérgio Sereno