Magento 2 使用 Redis 保存缓存或 Session 后，如果出现 Connection refused、read error on connection、页面 503 或后台频繁退出，应先确定故障发生在网络、认证还是 Redis 资源层，不要直接删除全部 Redis 数据。

1. 确认 Redis 服务和端口

redis-cli -h 127.0.0.1 -p 6379 ping
ss -lntp | grep 6379
systemctl status redis

正常情况下 ping 返回 PONG。如果 Magento 和 Redis 位于不同容器或服务器，127.0.0.1 指向的是当前容器，不一定是 Redis 主机。应使用部署环境提供的服务名称或内网地址。

2. 检查 Magento 实际配置

Redis 连接信息通常位于 app/etc/env.php 的 cache、page_cache 或 session 节点。三个用途可以使用不同数据库编号，避免清理缓存时误删 Session。

'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => 'redis',
        'port' => '6379',
        'database' => '2',
        'timeout' => '2.5'
    ]
]

修改前先备份 env.php，并确认代码部署不会覆盖环境配置。密码、哨兵和 TLS 参数必须以当前 Magento 版本与基础设施的实际配置为准。

3. 验证认证和数据库编号

redis-cli -h redis -p 6379 --user app ping
redis-cli -h redis -p 6379 INFO keyspace

不要把真实密码直接写进命令历史。可以通过受保护的配置文件或安全的环境变量传递认证信息。若使用 Redis ACL，应确认用户允许访问所需命令和数据库。

4. 检查内存与连接数

redis-cli -h redis INFO memory
redis-cli -h redis INFO clients
redis-cli -h redis INFO stats

重点观察 used_memory、maxmemory、connected_clients、blocked_clients 和拒绝连接数量。Redis 达到内存上限后，不同淘汰策略会产生完全不同的表现；Session 数据不应使用可能随机淘汰关键会话的策略。

5. 区分短暂故障和持续故障

偶发 read error 可能来自网络抖动、Redis 重启、连接空闲超时或主从切换。持续 Connection refused 通常表示地址、端口、防火墙或服务状态错误。应按时间把 Magento 日志、Redis 日志和基础设施事件对应起来。

修复后的验证

  1. 执行 bin/magento cache:status，确认 CLI 能连接。
  2. 连续访问前台和后台，确认 Session 不丢失。
  3. 清理一个 Magento 缓存类型，确认没有影响登录会话。
  4. 观察 Redis 内存、连接数和错误日志至少一个业务高峰。

不要把重启 Redis 当作最终修复。只有找出连接失败的具体层级，并确认缓存和 Session 都稳定，问题才算解决。