用户浏览十几分钟后偶尔被退出，后台管理员也会随机回到登录页。应用日志没有明确异常，清缓存还能短暂缓解。最后发现不是认证代码，而是 Redis 会话实例在内存压力下淘汰 key。

先把掉线发生在哪一层分清

浏览器仍携带 session cookie，只能证明会话编号还在；Redis 中对应 key 消失，Magento 一样会创建新会话。复现时记录响应头、Cookie 名和发生时间，然后检查：

redis-cli INFO memory
redis-cli INFO stats
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy
redis-cli --latency

evicted_keys 持续增长是强信号。缓存和 session 不宜混在同一个小实例里，否则缓存膨胀会把登录态一起挤掉。

TTL 与 Magento 配置要对得上

核对 env.php 的 session 配置、后台 Cookie Lifetime 和 Redis 实际 TTL。爬虫、顾客与管理员会话的生命周期可能不同，min_lifetime、max_lifetime 也会参与限制。

若日志有连接超时，查 Redis 连接数、网络抖动和超时，而不是继续提高 Cookie Lifetime。超时调得过长只会让 PHP worker 堵得更久。

锁等待也可能被误判为掉线

同一用户并发 AJAX 时，session locking 会让请求串行。锁等待超阈值后，前端可能把失败当成重新登录。把 PHP 慢请求、Redis 延迟和浏览器 Network 对齐，确认是 key 丢失还是锁等待。

验收要看 evicted_keys 不再增长、内存有余量、TTL 合理，并做同账号多并发测试。四项都稳定，随机掉线才算修好。