这是个很典型的「配置一致但行为不一致」的问题，结合ASP.NET 4.5的运行机制和你的场景，我梳理几个最可能的原因，以及对应的排查步骤：

一、MachineKey确实被更高优先级的配置覆盖了 #

你提到web.config里硬编码了machineKey，但ASP.NET的配置加载是有优先级的，应用级的web.config并不是最高优先级，以下几种情况会覆盖它：

• IIS的applicationHost.config配置：这是最容易忽略的点。如果有人在第二台服务器的IIS中，通过「配置编辑器」或者appcmd命令设置了machineKey，这个配置会存储在C:\Windows\System32\inetsrv\config\applicationHost.config里，优先级高于web.config。比如：

  <location path="YourWebAppName">
    <system.webServer>
      <asp>
        <machineKey decryption="AES" decryptionKey="..." validation="SHA1" validationKey="..." />
      </asp>
    </system.webServer>
  </location>
  

  这种情况下，即使web.config里有设置，IIS会优先用applicationHost.config里的。

• 服务器级别的machine.config锁定配置：虽然概率较低，但如果第二台服务器的machine.config（路径通常是C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config，x64对应Framework64目录）里的machineKey被设置了overrideModeDefault="Deny"，会禁止应用级配置覆盖它。不过你单独跑第二台时正常，所以这个可能性相对小。

排查动作：
在WebAPI中临时添加一个接口，直接输出当前应用实际加载的machineKey配置：

using System.Web;
using System.Web.Configuration;
using System.Web.Http;

public class DebugController : ApiController
{
    [HttpGet]
    public IHttpActionResult GetMachineKey()
    {
        var machineKeySection = WebConfigurationManager.GetSection("system.web/machineKey") as MachineKeySection;
        if (machineKeySection == null)
        {
            return NotFound();
        }

        return Ok(new
        {
            DecryptionAlgorithm = machineKeySection.Decryption,
            DecryptionKey = machineKeySection.DecryptionKey,
            ValidationAlgorithm = machineKeySection.Validation,
            ValidationKey = machineKeySection.ValidationKey
        });
    }
}

分别访问两台服务器的这个接口，对比返回的密钥是否和web.config完全一致。如果第二台的不一样，就实锤是配置被覆盖了。

二、负载均衡器的请求转发异常 #

虽然你说负载均衡器没有变更，但有可能出现针对第二台服务器的请求被篡改的情况：

• 负载均衡器的某些HTTP头处理规则，比如对Authorization头进行了编码、截断或者修改；
• 某些WAF（Web应用防火墙）规则在转发到第二台时误修改了令牌内容。

排查动作：

1. 启用两台服务器的IIS日志，确保日志中记录Authorization头（在IIS日志设置里勾选「Authorization」字段）；
2. 对比两台服务器收到的同一请求的Authorization头内容，看令牌是否完全一致；
3. 直接向第二台服务器发送测试请求（绕开负载均衡器），用相同的Bearer令牌验证是否正常——如果正常，那问题肯定出在负载均衡器。

三、服务器环境的隐性差异 #

你提到没有已知的环境变更，但以下隐性变化可能导致问题：

• .NET Framework补丁差异：Windows自动更新可能给第二台服务器安装了.NET Framework的补丁，而第一台没更。某些补丁会调整ASP.NET的加密/验证逻辑，导致令牌验证失败；
• 系统时间不一致：Bearer令牌（尤其是JWT）依赖系统时间验证过期时间，如果第二台服务器的时间比第一台慢/快超过令牌的有效期，会导致验证失败。

排查动作：

1. 对比两台服务器的.NET Framework版本：运行reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"，查看Version值是否一致；
2. 检查两台服务器的系统时间，确保都同步到同一个NTP服务器，时间差在1分钟以内。

四、应用程序池的状态问题 #

虽然单独跑第二台时正常，但负载均衡双开时，第二台的应用程序池可能出现缓存异常：

• 应用程序池启动时加载了错误的machineKey配置，之后没有重新加载；
• 应用程序池的回收策略导致配置加载异常。

排查动作：
手动重启第二台服务器的应用程序池，然后测试负载均衡双开的情况，看是否解决问题。

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