redis从节点默认会自动重连主节点，前提是repl-ping-replica-period和repl-timeout等配置未被禁用或设为极小值，且主节点地址、认证、网络路径有效；slaveof命令仅用于手动重建主从关系，不参与自动重连机制。
slaveof 命令不是自动重连机制，而是手动触发主从关系重建的指令。Redis 主从同步断开后能否“自动重连”，取决于你控制的是哪一侧、用什么方式管理连接，以及 Redis 版本和客户端行为。
主从连接断开 ≠ 客户端连接断开
这是最容易混淆的一点：主从同步链路（replication link）和应用客户端连接（client connection）是两套独立机制。slaveof、replicaof 是从节点向主节点发起的复制连接，它不依赖应用层客户端，也不走 redis-cli 或 Jedis/Lettuce 这类 SDK。一旦该链路断开，Redis 从节点默认会持续尝试重连——但前提是配置没被人为禁用或覆盖。
从节点自身是否自动重试？看配置项 repl-timeout 和 repl-ping-replica-period
Redis 从节点内置重连逻辑，无需外部干预，但行为受以下参数控制：
-
repl-ping-replica-period：从节点每隔多少秒向主节点发PING，默认 10 秒。若超时未响应，会标记主节点疑似下线 -
repl-timeout：复制连接建立/保持过程中的超时阈值，默认 60 秒。低于该值则主动断开并重试 -
repl-backlog-size：主节点复制积压缓冲区大小。越大越能容忍网络抖动导致的短暂断连（配合 Redis 2.8+ 的增量同步）
只要这些值未被设为 0 或极小值，且从节点配置中未显式执行 replicaof no one，它就会在断开后持续尝试重连主节点——日志里会出现 Connecting to MASTER、MASTER REPLICA sync started 等记录。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么有时“重连失败”？常见卡点
自动重连失败通常不是因为 Redis 不重试，而是被外部条件阻断：
- 主节点已关闭或地址变更，但从节点配置仍指向旧 IP/端口（
replicaof配置未更新） - 主节点设置了
requirepass，但从节点没配masterauth，每次重连都因认证失败退出 - 防火墙/NAT 设备拦截了从节点到主节点的 TCP 连接（尤其云环境 SLB 默认 900 秒空闲超时，而
repl-ping-replica-period默认 10 秒，本应够用；但若中间设备策略更激进，仍可能切断） - 主节点内存不足或
maxmemory触发淘汰，导致SYNC或PSYNC被拒绝
集群模式下主从切换后的重连逻辑完全不同
如果你用的是 Redis Cluster，主从关系由集群总线动态维护，slaveof 命令完全无效。此时重连由 CLUSTER FAILOVER 或哨兵（Sentinel）驱动：
- Sentinel 检测到主节点宕机后，会自动选举新主，并向所有已知从节点广播
SENTINEL replica-OF命令 - 从节点收到后立即执行
replicaof <new-master-ip><port></port></new-master-ip>，完成角色切换与重连 - 应用客户端需使用支持 Sentinel 的 SDK（如 Lettuce 的
RedisSentinelConfiguration），否则无法感知新主地址
单纯靠从节点自己轮询旧主地址，永远连不上新主。
真正需要人工介入的，往往不是“要不要重连”，而是“重连的目标是否还有效、权限是否匹配、路径是否通”。自动重连本身是 Redis 内建能力，但它的成败高度依赖配置一致性与基础设施稳定性。
