ASP.NET Identity授权会话与Cookie本地正常，远程服务器1分钟失效

兄弟，我之前也踩过ASP.NET Identity部署到服务器后会话秒丢的坑，结合你的情况（本地正常、远程仅1分钟有效），大概率是这几个配置出了问题，你逐个排查试试：

1. 明确配置Identity Cookie的过期时间 #

你的ConfigureAuth代码里可能没显式设置Cookie过期策略，远程服务器的默认配置可能被修改过。建议在Cookie认证配置里明确指定过期时间和滑动过期：

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
    {
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(30), // 身份验证间隔，建议设长一点
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
    },
    // 核心配置：设置Cookie过期时长
    ExpireTimeSpan = TimeSpan.FromHours(8), // 比如设置8小时有效期
    SlidingExpiration = true // 开启滑动过期，用户活跃时自动延长有效期
});

重点：如果不设置ExpireTimeSpan，默认有效期可能受服务器全局配置影响，容易出现短时间失效的情况。

2. 检查IIS应用池的回收策略 #

远程服务器的IIS应用池如果配置了短时间回收，会直接导致会话丢失：

• 打开IIS管理器，找到你的项目对应的应用池，右键选择「高级设置」
• 查看「回收」板块：确保「固定时间间隔（分钟）」不是1分钟（默认是1740分钟，也就是29小时）
• 再看「进程模型」里的「闲置超时（分钟）」，不要设置得太短（比如不要小于20分钟）

另外，也检查站点的「会话状态」配置：在IIS功能视图里找到「会话状态」，把超时时间设为20分钟以上。

3. 配置固定的Machine Key #

远程服务器默认会自动生成Machine Key，一旦应用池回收或服务器重启，密钥就会变化，导致Identity的Cookie无法验证，直接失效。解决方法是在web.config里添加固定的Machine Key：

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

你可以用Visual Studio的工具或者密钥生成器生成固定的密钥，确保密钥不会随服务器重启或应用池回收而改变。如果是多服务器集群，所有服务器必须用同一个Machine Key。

4. 确认Session状态配置（如果用到Session） #

如果你的项目依赖ASP.NET Session，检查web.config里的Session配置：

<system.web>
  <sessionState mode="InProc" timeout="20" /> <!-- 单服务器用InProc即可，超时设长一点 -->
</system.web>

如果是多服务器环境，InProc模式不行，需要改用StateServer或SQL Server模式来共享会话。

5. 排查反向代理/负载均衡的影响 #

如果你的服务器前面有反向代理（比如Nginx、Azure App Service的代理）或负载均衡，可能会因为代理的超时设置或请求头传递问题导致会话失效：

• 确保代理服务器传递了正确的请求头（比如X-Forwarded-For、X-Forwarded-Proto）
• 把代理服务器的超时时间设置得比你的会话超时时间更长

建议你先从配置Cookie过期时间和Machine Key开始排查，这两个是最常见的触发原因。本地环境因为Machine Key固定、应用池不会频繁回收，所以不会出现这类问题。

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