Azure Web App上高可用ASP.Net MVC出现500内部服务器错误

首先，咱们得先定位500错误的具体根源——毕竟“Internal Server Error”只是个笼统的提示，看不到具体异常的话很难精准排查。我遇到过很多类似的Web场配置问题，大多和Machine Key配置不严谨或者会话状态未分布式化有关，下面一步步来解决：

第一步：捕获详细的500错误详情 #

默认情况下Azure Web App不会显示详细的服务器错误，咱们得先开启日志或者修改配置来获取具体异常：

• 修改web.config：在<system.web>节点下添加或修改：

  <customErrors mode="Off" />
  <compilation debug="true" />
  

  注意：生产环境调试完成后要改回mode="RemoteOnly"和debug="false"，避免安全风险。
• 查看Azure日志：在Azure门户进入你的Web App，依次点击「诊断和解决问题」->「日志流」，或者「配置」->「诊断设置」开启应用日志，登录时的错误会在这里显示具体的异常信息（比如“验证票证解密失败”之类的提示）。

第二步：确保Machine Key配置完全一致且正确 #

Machine Key是Web场中共享加密/解密上下文的核心，你的问题大概率出在这里，推荐用Azure应用设置来配置（比硬编码web.config更安全且易同步）：

• 登录Azure门户，分别进入两个Web App的「配置」->「应用设置」，添加以下4个配置项，两个实例的取值必须完全相同：
  • WEBSITE_MACHINE_KEY_VALIDATION_KEY：你的验证密钥（比如生成的32位或64位随机字符串）
  • WEBSITE_MACHINE_KEY_DECRYPTION_KEY：你的解密密钥
  • WEBSITE_MACHINE_KEY_VALIDATION：加密算法（推荐HMACSHA256）
  • WEBSITE_MACHINE_KEY_DECRYPTION：解密算法（推荐AES）
• 如果你坚持手动修改web.config，确保<system.web>下的machineKey节点完全一致，没有空格、大小写错误：

  <machineKey validationKey="你的验证密钥" 
             decryptionKey="你的解密密钥" 
             validation="HMACSHA256" 
             decryption="AES" />
  

  注意：不要在密钥中包含多余的换行或特殊字符，生成密钥时要确保是符合ASP.NET要求的格式。

第三步：配置分布式会话状态 #

ASP.NET MVC默认的InProc会话状态只能在单个实例内生效，Web场环境下必须改用分布式会话，否则用户登录后切换实例会丢失会话，甚至触发错误：

选项1：Azure Redis Cache（推荐，性能更高） #

1. 部署一个Azure Redis Cache实例，获取主机名、访问密钥和端口。
2. 在web.config中添加SessionState配置：

   <sessionState mode="Custom" customProvider="RedisSessionProvider">
     <providers>
       <add name="RedisSessionProvider" 
            type="Microsoft.Web.Redis.RedisSessionStateProvider" 
            host="你的Redis主机名" 
            accessKey="你的Redis访问密钥" 
            port="6380" 
            ssl="true" />
     </providers>
   </sessionState>
   

选项2：SQL Server会话状态 #

1. 准备一个Azure SQL Database（推荐用异地复制保证数据库高可用），运行aspnet_regsql.exe工具创建会话状态表。
2. 在web.config中配置：

   <sessionState mode="SQLServer" 
                sqlConnectionString="你的SQL连接字符串" />
   

第四步：保证两个Web App的部署完全一致 #

• 使用CI/CD工具（比如Azure DevOps、GitHub Actions）同时部署代码到两个实例，避免手动部署导致的web.config、依赖包差异。
• 检查两个实例的连接字符串是否指向同一个高可用数据库（比如Azure SQL的异地副本），确保数据库层也满足HADR要求。

第五步：完成Azure HADR架构的最终配置 #

如果你的两个Web App是跨区域部署的，还需要配置Azure流量管理器来实现故障转移和负载均衡：

1. 创建一个流量管理器配置文件，选择「故障转移」路由方法。
2. 添加两个Web App作为端点，设置优先级（比如主区域实例优先级1，灾备区域优先级2）。
3. 将流量管理器的域名作为用户访问的入口URL，这样当主区域实例故障时，会自动切换到灾备实例。

按照以上步骤排查和配置后，登录时的500错误应该就能解决，同时你的ASP.NET MVC应用也能在Azure上实现真正的高可用灾难恢复架构。

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