Asp.net 会话超时意外值9999

我知道会话超时的范围是1-9999，默认为（10或600？）

My web.config设置会话状态超时=“5”

我有一些带有

@Session.Timeout

剃须刀的评估结果与预期一样为

5

，我可以在任何地方进行故障排除

除了在生产中。如果我查看生产网站的HTML，Razor

@Session.Timeout

所在的位置会显示

9999

构建服务器上的Web.Config显示

SessionState timeout=“5”

，该Web.Config直接复制到自动构建中的产品位置（我无权访问）

最后：代码中有0个调用来更改HttpSessionState

---

原因可能是什么？

某些内容覆盖了您的应用程序web.config

你能在web.config之前和之后检查一下吗

第一个是Machine.config

systemroot\Microsoft.NET\Framework\versionNumber\config\Machine.config

第二个是ApplicationHost.config

%windir%\system32\inetsrv\config

第三个是rootWeb.config

systemroot\Microsoft.NET\Framework\versionNumber\config\Web.config

---

此外，您还应检查简化it

一些需要检查/尝试的事项：

检查ApplicationHost.config文件，查看是否在其中定义了会话超时

如果您使用的是表单身份验证，请检查此部分，查看是否存在不正确的值：

<authentication mode="Forms">
    <forms timeout="9999" ... />
</authentication>

在global.asax的

会话_Start

中有什么聪明的事情吗？有些人喜欢在课程刚开始时在这里玩

---

如果无法在生产环境中查看web.config，您得到的任何答案都只是猜测。此外，“Web.Config在自动构建中直接复制到prod位置”这一事实听起来是错误的；数据库连接字符串、编译键等应该在站点部署时更改。它们在发布转换到构建服务器时更改。当发布管理客户端说“继续！”时，它被认为是直接复制到生产中的。Fredou，谢谢你的回复。我已请求服务器团队从服务器的所有节点向我发送计算机和AppHost。当然，这不太可能有问题，但这是我收到的唯一新方向。让我们看看结果如何。我检查了实际生产web.config之外的所有内容，但找不到任何内容。尽管他们都很合法，而且是解决这个问题的最佳答案。不幸的是，在成为吱吱作响的轮胎之后，我终于发现web.config将9999硬编码为超时。我讨厌不能信任这个过程，但这就是问题所在。它提出了一个问题，现在我只需要帮助解决改进流程的问题=-汉克斯！那是一个合法的检查场所+1用于添加信息。