Chrome访问Tomcat时每次请求生成新HttpSession的配置咨询

这个问题我之前帮不少开发者排查过，Chrome下每次登录都生成新Session的核心原因，基本都是JSESSIONID Cookie没有被正确持久化或传递。结合你Tomcat 8+IIS+isapi_redirect的部署环境，你可以按下面的步骤逐一排查配置：

1. 调整Tomcat的Session Cookie属性 #

Chrome对Cookie的安全限制比Firefox和IE更严格，你需要在Tomcat的conf/context.xml里明确配置Cookie的关键属性：

<Context 
  sessionCookieSameSite="Lax" 
  sessionCookieSecure="true" 
  sessionCookieHttpOnly="true"
>
  <!-- 你的其他Context配置 -->
</Context>

• sessionCookieSecure：如果你的站点用HTTPS，必须设为true，Chrome会拒绝非HTTPS环境下标记为Secure的Cookie；如果是HTTP环境，改为false。
• sessionCookieSameSite：设为Lax是最兼容的选项，既符合Chrome的安全要求，又不会影响正常的Session传递；如果是跨域场景（比如IIS和Tomcat在不同域名），可能需要设为None，但None必须配合sessionCookieSecure="true"。
• sessionCookieHttpOnly：这是安全最佳实践，防止XSS攻击窃取Cookie，不影响Session正常工作。

2. 确保IIS的isapi_redirect正确传递Cookie #

IIS作为反向代理时，很容易不小心过滤或修改Cookie，你需要检查这些配置：

• 打开isapi_redirect.properties（或你的worker配置文件），设置正确的Cookie域名：

  worker.your_worker_name.cookie_domain=your_domain.com
  

  把your_worker_name和your_domain.com替换成你实际的worker名称和站点域名，确保Cookie绑定到正确的域名范围。
• 检查IIS的HTTP响应头设置：进入站点的「HTTP响应头」，确保没有自定义的Set-Cookie规则覆盖Tomcat生成的JSESSIONID Cookie。
• 排查URL重写规则：如果你的IIS配置了URL Rewrite模块，确保规则没有删除或修改Cookie请求头。

3. 验证Session ID的传递流程 #

用Chrome开发者工具（F12打开「网络」标签）抓包验证：

• 登录请求的响应头里，是否包含Set-Cookie: JSESSIONID=xxx; ...，且属性和你在Tomcat里配置的一致。
• 后续访问受保护页面的请求头里，是否携带Cookie: JSESSIONID=xxx。
  • 如果响应有Cookie但请求没带：说明Chrome拒绝保存Cookie，大概率是SameSite或Secure属性不匹配。
  • 如果响应里根本没有Set-Cookie：说明Tomcat没生成Session Cookie，检查conf/web.xml里的<session-config>是否强制使用了URL追踪（优先用Cookie追踪）：

    <session-config>
      <tracking-mode>COOKIE</tracking-mode>
    </session-config>
    

4. 排除用户端Chrome设置问题 #

虽然优先从服务端解决，但可以让测试的用户检查Chrome的Cookie设置：打开chrome://settings/cookies，确保你的站点没有被设置为「阻止所有Cookie」，如果是跨域场景，要允许第三方Cookie。不过这个是临时方案，最终还是要靠服务端配置兼容。

按上面的步骤排查，基本能解决Chrome下Session重置的问题。如果还是不行，可以把开发者工具里的Cookie相关请求/响应头贴出来，方便进一步定位。

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