采用Azure AD的.NET项目双负载均衡环境下出现重定向过多错误

看起来你遇到的是负载均衡环境下Azure AD单点登录的经典重定向循环问题——本地正常是因为没有负载均衡带来的环境差异，下面是几个最可能的原因和对应的解决办法：

1. 负载均衡器未正确传递HTTPS请求头 #

Azure AD要求回调地址必须是HTTPS，但如果负载均衡器做了SSL卸载（即负载均衡器处理HTTPS，后端服务器用HTTP通信），你的应用可能会误以为自己运行在HTTP环境下，导致Azure AD回调后应用又重定向到HTTPS，形成循环。

解决办法：

• 先配置负载均衡器传递X-Forwarded-Proto、X-Forwarded-For这类转发头；
• 在你的.NET项目中添加转发头处理逻辑：
  如果是传统ASP.NET（非Core），在Global.asax里添加：

  protected void Application_BeginRequest()
  {
      if (Request.Headers["X-Forwarded-Proto"] == "https")
      {
          HttpContext.Current.Request.ServerVariables["HTTPS"] = "ON";
          HttpContext.Current.Request.ServerVariables["SERVER_PORT"] = "443";
      }
  }
  

  如果是ASP.NET Core，在Program.cs或Startup.cs中启用转发中间件：

  app.UseForwardedHeaders(new ForwardedHeadersOptions
  {
      ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
  });
  

2. 未配置会话粘性或共享MachineKey #

负载均衡的两台服务器如果没有会话亲和性（粘性会话），同一个用户的请求可能在两台服务器间来回跳转；而传统ASP.NET的认证票据是基于服务器的MachineKey加密的，不同服务器的MachineKey不同的话，另一台服务器无法解密票据，会重新触发认证，导致重定向循环。

解决办法：

• 方式一：在负载均衡器上开启会话粘性（比如基于Cookie或IP），让同一用户的请求始终路由到同一台服务器；
• 方式二：给两台服务器配置相同的MachineKey，在web.config的<system.web>节点下添加：

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

  （可以用安全的密钥生成工具生成密钥，确保两台服务器的配置完全一致）

3. Azure AD应用注册的回调地址配置错误 #

检查你在Azure AD中注册的应用的重定向URI，确保：

• 包含部署后的HTTPS域名（比如https://xxx.com/signin-oidc，具体路径根据你的认证中间件配置）；
• 没有多余的HTTP回调地址，否则可能导致Azure AD回调到HTTP地址，又被应用重定向到HTTPS；
• 回调地址和应用中配置的RedirectUri完全一致。

4. 认证中间件的权威域名配置问题 #

如果应用在负载均衡后使用的是外部域名，而认证中间件的Authority或相关配置没有正确指向外部域名，也可能导致重定向循环。比如ASP.NET Core中，需要确保AddOpenIdConnect的配置里，CallbackPath和外部域名的路径匹配，同时启用转发头让应用识别真实的请求域名。

最后，临时可以清除浏览器的Cookie和缓存，但这只是缓解症状，根本解决还是要调整上面的配置。

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