最近陆续有用户反馈在我们网站上登录时遇到登录死循环问题。输入用户名与密码提交后，显示登录成功，但跳转到目标网址后（由于依然处于未登录状态）又跳转回登录页面，再次登录，再次这样。。。就这样一直循环，怎么也登录不进去。
排查了几天，从我们自身的角度实在找不到线索。昨天不得不把怀疑的目光转向阿里云负载均衡 —— 可能是负载均衡的某种网络问题造成浏览器没有接收到有效的登录Cookie，换个负载均衡试试。我们联系了持续被这个问题困扰的用户，得知她用的是联通的线路上网的，于是我们创建了新的负载均衡，将联通线路的请求解析到这台新的负载均衡，结果那位用户遇到的问题竟然神奇地解决了。当时我们想可能是因为部分联通用户的线路与登录站点所用负载均衡之间的某种网络问题。
今天，我们在闪存上发现还有用户遇到这个问题，心想可能其他线路与登录站点的负载均衡也有某种网络问题，干脆将所有请求都切换到昨天新创建的负载均衡。在切换后，在偶然的情况下，我们自己的一台电脑也遇到了这个问题。我们立马看了一下登录后负载均衡返回的Cookie，意外地发现负载均衡竟然把后端服务器返回的Cookie修改错了，改成了：
正常的Cookie应该是这样的：
也就是负载均衡在植入Cookie时将以下形式的字符串：
".CNBlogsCookie={XXX}; domain=.cnblogs.com; path=/; HttpOnly.Cnblogs.AspNetCore.Cookies={YYY}; domain=.cnblogs.com; path=/; HttpOnlySERVERID={ZZZ};Path=/"
错误地改写为下面的字符串（不知道是不是代码中指针惹的祸）：
".CNBlogsCookie=; domain=.cnblogs.com; expires=Mon, 11-Oct-1999 16:00:00 GMT; path=/; HttpOnlySERVERID={ZZZ};Path=/"
负载均衡修改Cookie是由于我们开启了负载均衡的会话保持，并且选择了“植入Cookie”的Cookie处理方式。
我们“幸运”地遭遇这个问题，可能是因为我们的登录站点在返回Cookie时稍有特殊——返回了2个Cookie，一个是用于ASP.NET站点，一个是用于ASP.NET Core（我们目前正在进行ASP.NET Core迁移工作），正好触发了这个隐藏的bug。