Tomcat配置<session-timeout>是否存在15分钟的取值下限？

<session-timeout>配置项本身不存在15分钟的取值下限。Servlet规范仅明确该配置的单位为分钟，取值为0或负数时代表会话永不超时，完全支持设置1分钟、5分钟这类短超时值。配置后会话固定15分钟过期的核心原因是：你在web.xml中写的配置未实际生效，被更高优先级的配置或代码逻辑覆盖了。

• 权限框架接管会话，覆盖容器配置
  项目如果引入了Shiro、Spring Security这类权限框架，框架会独立接管会话生命周期，不会读取Tomcat的web.xml配置。其中Shiro的默认全局会话超时时间恰好是15分钟（900000毫秒），是这类问题最高频的诱因。
• 代码硬编码超时值
  如果在业务代码、过滤器、拦截器中调用了session.setMaxInactiveInterval(900)方法，该API的优先级高于所有配置文件，会直接把会话超时固定为15分钟。
• 上层Tomcat配置覆盖或配置解析失败
  Tomcat采用多级配置加载逻辑，如果你在Tomcat全局配置conf/web.xml、应用独立上下文配置文件（路径为conf/Catalina/localhost/[你的应用名].xml）中配置了15分钟会话超时，且应用自身的web.xml存在标签未闭合、Schema版本不匹配等格式错误时，Tomcat会跳过错误配置，回退加载上层的15分钟超时设置。
• 配置改动未重新加载
  修改web.xml后如果没有重新部署应用、重启Tomcat上下文，服务器仍会运行旧版本配置，改动不会生效。Tomcat默认不会热加载web.xml的变更，生产环境一般也会主动关闭热部署能力。

• 第一步先确认实际生效的超时值：在任意可正常访问的业务接口中打印request.getSession().getMaxInactiveInterval()，该方法返回值单位为秒：返回900即代表当前生效的是15分钟超时，返回300对应5分钟、60对应1分钟，先定位配置是否被正确加载。
• 如果打印结果为900（15分钟）：
  • 全局搜索项目代码，找到所有setMaxInactiveInterval的调用点，删除硬编码的15分钟设置，或调整为目标值。
  • 检查项目引入的安全框架配置：Shiro需调整globalSessionTimeout配置项（单位为毫秒），Spring Boot/Spring Security需调整server.servlet.session.timeout配置项。这类框架配置的优先级高于web.xml，仅修改web.xml不会生效。
  • 查看Tomcat启动日志catalina.out，确认应用web.xml没有XML解析报错，同时核查Tomcat全局web.xml、应用独立上下文配置文件中是否存在硬编码的15分钟会话超时配置，有则调整或删除。
  • 重新打包部署应用，重启Tomcat上下文后再验证，避免旧版本配置残留。
• 如果打印结果为你设置的目标值（300/60），但实际会话15分钟才过期：
  • 检查前端是否存在定时轮询接口、静态资源自动刷新的逻辑，这类请求会自动续期会话，重置过期计时。
  • 检查过滤器、拦截器逻辑，确认不存在每次请求都重置会话超时时间的代码。

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