登录网站总掉线？先别怪密码

输完账号密码进去了，点两下又被弹回登录页——碰上这种事，多数人第一反应是密码记错了，然后把密码改一遍、缓存清一遍、浏览器换个遍，问题还杵在那儿。登录网站总掉线，跟密码的关系通常不大，真正出问题的是”登录之后网站还认不认得你”。密码只负责开门，进门之后手里得一直攥着票，票丢了或者检票的不认，照样把你请回门口。这张票，就是会话（session）或者 token。

掉线分三种，混着治就是白费劲

同样是掉线，情况差得远。一种是提交完直接弹回登录页，压根没进去——多半是会话没写进去，或者写进去了浏览器没带上。一种是进去了能用一会儿，点着点着突然被踢出来——会话建住了但又丢了、或者过期了。还有一种是页面转圈转到底，根本没响应，那跟会话没关系，是请求超时、后端顶不住。这三种指向的方向完全不一样，混在一起修，就是碰运气。

登录网站后端一上多机，会话不共享就是各记各的

单机的时候，session 默认写本地文件，谁也碰不到谁，一直挺太平。一加机器、挂上负载均衡，事就来了：第一个请求分到 A，A 把 session 写在自己硬盘上；第二个请求被轮询扔给 B，B 翻了一圈没这号人，判定你没登录，踢回登录页。用户感受到的就是”刷新下好了，再点一下又掉了”，这种随机性特别磨人。做 sticky session（会话保持）能缓解，但靠源 IP 保持不太靠得住——同一个出口 IP 后面可能坐着整个办公室。更稳的是把 session 放到 Redis 这类共享存储，所有机器都去同一个地方查；容器环境尤其留心，pod 一重建，本地那份 session 就没了。再不然走无状态方案，让 token 自带身份，服务端不存。

Cookie 这块小事，能坑你一整天

细节能列一长串，真踩起来就那几个。带 www 的域名和不带 www 的，在浏览器眼里是两个站，cookie 各存一套，用户从一边跳到另一边，票就丢了。站点从 http 迁到 https 时，老 cookie 带不过去，Secure 没设对也漏。SameSite 设成 Strict，从别的站跳过来的第一个请求不带 cookie，用户会觉得”刚点进来就掉线”。还有 Path 设窄了、后台换过域名 cookie 的 domain 没跟着改、浏览器对第三方 cookie 越收越紧。查的时候不用猜，F12 打开 Application 里的 Cookies，登录前后各看一次，Domain、Path、Secure、SameSite、过期时间挨着对一遍；再去 Network 看请求头有没有带上 Cookie、响应头有没有 Set-Cookie，基本就露馅了。

反向代理背后那几十秒的超时

掉线要是有规律，比如每次都差不多隔几分钟，那八成是某个超时参数在作怪。Nginx 反代到后端有 proxy_read_timeout，默认 60 秒；php-fpm 那边有 request_terminate_timeout 和 max_execution_time；负载均衡、网关、CDN 各有一层空闲超时，链路上串了一排参数，任何一环先到点，连接就断。session 文件锁也是常见的坑：同一个 session 的请求在 PHP 里是串行的，页面上挂个长轮询或者大文件上传，其它请求全排队，用户那边看着就是卡死、掉线。反代还有个经典问题，X-Forwarded-Proto 没往后端传，程序以为用户还在 http 上，于是不停往 https 跳，跳成循环，页面直接打不开。

WAF 和风控也会把人”踢”出去

有时候不是掉线，是被拦了。WAF 或者风控看到短时间请求太密、参数长得像注入、IP 换了地方、UA 变了，就把请求丢去做验证，用户看到验证页或者一片白，第一反应还是”又掉线了”。这类在日志里长得不一样，去翻拦截记录，看返回的是 403 还是 302 跳验证，一眼能分开。自家写的风控也算上：异地登录、同账号多设备、切换网络，都会触发踢人。规则是保护，但阈值定得太紧，天天误伤自己人。

token 也不是免死金牌

换成 token 不代表就太平了。JWT 那套方案里，过期时间设得太短、刷新接口又写得半对不对，用户就会被反复登出；多台服务器时钟不同步，一台认为没过期、另一台认为已经过期，表现出来同样是随机掉线；多标签页同时刷 token，后刷的把前一个覆盖掉，另一个标签页下次请求就 401。token 存 localStorage 的，用户清一次浏览器数据就没了，这个得心里有数。

排查按这个顺序走，少绕路

顺序大概是这样：先问清楚，是所有人都这样还是少数人，是固定间隔还是随机，手机电脑都犯还是只有某一台；固定间隔的，去翻超时和过期参数，别在业务代码里瞎找；随机的，重点盯多机会话和 cookie。F12 里看三样，请求头有没有 Cookie、响应是不是 302 回登录页或者 401、Set-Cookie 有没有下发。服务端把这几份日志对一遍，Nginx 的 access/error、应用错误日志、Redis 连接有没有断。复现的时候开两三个浏览器，手机用流量再试一遍，不少问题只在特定网络环境下冒头。最后，改的时候一次只动一个变量，一口气改五个地方然后好了，你也不知道是哪个起的作用，下次再犯还得从头查。

掉线这事最费时间的不是修，是找。先把它归进”会话没建住”还是”会话建住了又丢”这两类，方向立刻窄一大半。改完别只在你这台电脑上试，换个浏览器、换张手机卡再跑一遍，能少收好几条”还是不行”的反馈。