会员系统登录网站；掉线多是登录态没共享

会员系统登录网站这事，最烦人的不是登不上去，是登上去过一会儿又给你踢出来。用户骂骂咧咧找客服，客服转技术，技术打开监控一看：CPU 不高，带宽没跑满，数据库也活着，啥毛病没有。这时候多半得往一个地方想——登录态到底存在哪儿，几台后端有没有共享。密码错了会一次都登不进，网络差会整页打不开，唯独这种“登进去又掉出来、刷新两下又好了”的，十有八九是会话没接上。

会员系统登录网站为什么总在关键时候掉线

多数程序默认把 session 写成文件，扔在服务器本地某个目录里。php.ini 里那项叫 session.save_path，没改过的话可能是 /tmp，也可能是 /var/lib/php/sessions 之类。单机跑一点问题没有：用户第一次访问生成一个会话文件，后面每次请求带着 Cookie 里的 PHPSESSID 回来，服务器一查文件还在，认你。可前面一旦挂了负载均衡、后面两台以上应用服务器，这事立刻变味。

用户第一次请求落到 A 机，会话文件写在了 A 机的磁盘上。第二次请求被均衡到 B 机，B 机把自己的目录翻了个遍也找不着这个 ID，只能当你是陌生人，重新发一个。表现就是刚登录完点了两下菜单，人又被送回登录页。用户以为是网络抽风，其实是他被两台机器轮流踢。

掉线的样子差不多，原因能差很远

有些是整点掉，有些是刷新几次才好，有些只有手机流量掉、连上 WiFi 就没事。这几种指向的东西完全不同。整点掉要怀疑定时任务清了临时目录，或者哪台机器半夜重启过；只在移动网络下掉，多半跟按源 IP 做会话保持有关，运营商出口换一个地址，用户就被分到另一台机器去了。

还有个特别容易忽略的：虚拟主机上同一个临时目录被好几个站点共用，会话文件名撞车是常事；有的主机商还会定期清理临时目录，你的会话本来活得好好的，文件先没了。这类问题查不到报错，日志干干净净，只能靠现象反推。

共享登录态，几条路各有各的坑

最直接的是把会话挪出去，存 Redis 或者 Memcached。改几行配置就行，session.save_handler = redis，session.save_path = “tcp://127.0.0.1:6379″，几台机器连同一个实例，谁都能认。坑在于过期时间要跟 session.gc_maxlifetime 对齐，不然程序这边认为会话还有效，Redis 那边早就把它清了。还有，别让 Redis 挂了导致整站登录不了，得留个降级路子。

存数据库也能用，读写频繁一点，量不大其实无所谓，好处是备份和排查都直观。粘性会话最省事，在负载均衡上按 cookie 插入或者源 IP 哈希，让同一个用户始终落同一台。缺点很明显：那台机器一重启或者一扩容，上面的用户集体掉一次；IP 哈希在移动网络下更不靠谱，用户坐趟地铁就换出口了。

token 那套看着最先进，服务端不存状态，多机天然一致。可注销、踢人、临时改权限这些需求一上来就很别扭，还得再引入一个黑名单存储，绕一圈又回到有状态的老路上。选哪条不取决于谁先进，取决于你有几台机器、允不允许掉一次。

cookie 域和 HTTPS 也常背这个锅

用户从带 www 的地址点进来，登录之后站内链接跳到了不带 www 的域名，Cookie 的 domain 没写成 .example.com 这种带点的形式，浏览器就当成两个站，登录态当场没了。还有给 cookie 加了 Secure 标志，但站里有些页面还挂在 http 上，那几个页面根本读不到 cookie。SameSite 设得严的话，从外部链接跳回来也不带 cookie，用户看着像掉线，其实是被浏览器拦了。

这几样查起来比会话共享快得多，先排掉再动后端。顺手提一句，如果前面套了 CDN，务必确认它没有缓存带 Set-Cookie 的响应，那种缓存一下能把不同用户的会话串到一起，比掉线严重多了，性质都不一样。

排查顺序，从浏览器那头开始掐

打开开发者工具，看 Application 里的 cookie，PHPSESSID 是不是每次请求都在变。变，说明服务端一直在给你发新的，问题在后端；不变但依然掉，问题在存储或者过期时间。再多刷几次，看响应头有没有重复的 Set-Cookie，重复多半是两台机器的配置不一致。

接着数后端有几台。curl -I 拿一次响应的会话 ID，去每台机器的会话目录里找一遍，哪台没有基本就锁定了。access log 也要翻，看同一个会话的请求是不是被打散到了不同机器。要是装了 Redis，直接 keys 一下看有没有对应前缀，比翻日志快。

共享之后还掉，看看这几个漏网的

会话共享做好了还是偶发掉线，先怀疑定时任务和自动伸缩，机器一进一出，内存里的东西就没了。再就是 PHP 的会话文件锁，同一个会话的并发请求会被排队，用户感觉是页面转圈卡住，不一定是掉线，但投诉起来语气一模一样。还有 APP 和 H5 共用一套账号的，两边各自生成会话、互相覆盖，掉得毫无规律。

先确认几台后端，再谈方案

只有一台应用服务器，别急着上 Redis，先看会话目录权限对不对、有没有被定时清理、磁盘满没满。两台以上，就别再用本地文件了，早晚出事，只是时间问题。三台以上还带弹性伸缩的，粘性会话只能当过渡方案，别当终点。

会员系统登录网站这种带账号的站点，掉线的代价比一般站高，用户第一反应不是“网络不好”，而是“这站是不是不安全”。真要动手，先在测试环境把两台机器指向同一个 Redis，拿同一个会话 ID 连续请求几十次，看是不是稳定认人，再上生产。改完记得把原来那套本地会话清理策略也调一调，别留着两套逻辑互相打架，那种坑往往过半年才冒出来。