C# HttpClient每次请求生成新SessionID Cookie无法持久化问题

你当前代码中已经将HttpClient、HttpClientHandler、CookieContainer声明为类级单例变量，仍然出现每次请求返回新sessionID、会话丢失的问题，直接对照以下高频踩坑点逐一排查即可：

• 自动重定向Cookie丢失bug
  你当前配置了handler.AllowAutoRedirect = true，在.NET Framework、.NET Core 3.1及更早版本中，该逻辑存在已知兼容问题：如果登录请求的重定向目标地址和原请求的scheme（http/https）、端口、域名/IP任意一项不一致，HttpClientHandler会默认丢弃原请求响应返回的Cookie，既不会写入CookieContainer，也不会自动带到重定向后的请求中。
  修复方式：将AllowAutoRedirect设为false，手动处理301/302重定向逻辑，每一步响应拿到Set-Cookie头后手动写入CookieContainer，再发起重定向地址的请求。
• 自定义Connection头触发设备兼容问题
  你代码中手动清除了默认Connection头、强制设置ConnectionClose = false开启长连接，大量局域网嵌入式设备的Web服务对长连接的会话识别逻辑存在缺陷，会将不同的长连接请求判定为全新会话，直接返回新的sessionID。
  修复方式：删除这两行Connection相关的自定义配置，使用默认请求头规则即可，也可以显式设置ConnectionClose = true，每次请求完成后关闭连接，反而能让设备正确关联会话Cookie。
• Cookie域/路径匹配规则不匹配
  直接在调试时调用cookies.GetCookies(你的请求地址)查看容器中实际存储的Cookie内容，绝大多数场景下你会发现服务端返回的Set-Cookie头携带的Domain属性和你实际请求的地址不匹配（比如服务端返回Domain为localhost，你实际用192.168.x.x发起请求；或者Domain带了多余的.前缀），这种情况下CookieContainer虽然存了Cookie，但不会自动附加到域不匹配的请求上，服务端收不到旧sessionID自然会返回新会话。
  修复方式：拿到响应的Set-Cookie头后手动创建Cookie对象，显式指定和请求地址匹配的Domain、Path属性，再调用cookies.Add()手动写入容器，不要完全依赖框架的自动Cookie解析逻辑。
• 请求头缺失校验字段
  Postman在重定向过程中会自动携带Referer、Origin、Accept等常规请求头，如果你代码里没补全这些头，部分设备的Web服务会判定请求为非法访问，直接重置会话返回新sessionID。
  修复方式：抓包对比Postman发送的请求头和你程序发出的请求头，把缺失的字段补全，保证两边请求头完全一致即可。
• Cookie头重复添加冲突
  如果后续业务请求中你手动给DefaultRequestHeaders或者单独请求的Headers里加了Cookie字段，会和CookieContainer自动附加的Cookie产生重复、冲突，服务端解析Cookie字段出错时，就会生成新的会话。
  修复方式：开启UseCookies = true后不要手动添加Cookie头，所有Cookie读写全交给CookieContainer处理。

排查小技巧：不要只打印请求时携带的Cookie，直接断点查看CookieContainer中存储的所有Cookie的Domain、Path、Expires属性，能快速定位是Cookie没存进去，还是存了但匹配规则不对没被带上。

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