CLUSTERDOWN本质是集群未达最小服务单元，需至少3个主节点在线且16384个Slot完整分配；先执行cluster info查cluster_state:fail、cluster_slots_assigned是否为0或远小于16384、cluster_size是否小于预期主节点数，再结合cluster nodes检查fail/noaddr状态及nodes.conf中IP是否匹配当前真实地址。
CLUSTERDOWN 报错本质是集群无法提供最小服务单元 —— 至少要有 3 个主节点在线且 slot 分配完整，否则任何客户端请求都会直接失败。
cluster info 显示 cluster_state:fail 怎么快速定位
先连任意一个节点执行 redis-cli -c -h <ip> -p <port> cluster info</port></ip>，重点看三行：
-
cluster_state:fail—— 集群未激活，不是“down”而是根本没起来 -
cluster_slots_assigned:0或远小于16384—— slot 没分配，集群空转 -
cluster_size:0或小于预期主节点数 —— 节点互相没认全，网络或配置堵在第一步
此时别急着重启，先查 cluster nodes 输出里有没有大量 fail 或 noaddr 状态，那基本是 IP/端口配置没对上。
nodes.conf 里 IP 写死导致集群“失联”
Redis 启动后会把实际监听地址写进 nodes.conf。如果用 Docker、VM 迁移或改过宿主机 IP，旧 nodes.conf 里存的还是老 IP（比如 192.168.1.100），新环境节点就互相 ping 不通。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 停所有节点：
redis-cli -h <ip> -p <port> shutdown</port></ip> - 删每个实例数据目录下的
nodes.conf和dump.rdb（保留redis.conf） - 确认
redis.conf中已设cluster-announce-ip为当前机器真实 IP（不能是127.0.0.1或0.0.0.0） - 再启动节点，重新跑
redis-cli --cluster create
客户端连得上但报 CLUSTERDOWN 的常见坑
工具（如 RedisInsight）能连、redis-cli -c 能 set，不代表你的应用代码能用 —— 它很可能用的是单节点客户端。
- Java 项目用
JedisCluster，不是Jedis；传入的节点列表必须包含至少 3 个主节点地址 - Go 项目用
go-redis/v8的redis.NewClusterClient()，不是redis.NewClient() - Python 用
redis.RedisCluster()，不是redis.Redis()；且初始化时要加skip_full_coverage_check=True（若 slot 未 100% 分配） - 检查客户端日志是否反复重试连接某一个挂掉的节点 —— 这说明它没走集群拓扑发现逻辑，配置漏了
slot 分配不均或缺失导致 cluster_slots_ok
即使所有节点都 running，只要有一个 slot 没被任何主节点接管，cluster_slots_ok 就会卡在小于 16384，状态永远 fail。
- 用
redis-cli -c -h <any-node> cluster slots</any-node>查哪些 slot 区间没被覆盖 - 如果输出里有空缺（比如只看到
0-5460和10923-16383），说明创建集群时没指定足够节点或中途失败 - 不要手动
cluster addslots—— 容易错，直接删配置重来更稳 - 重创建时确保命令里列出全部 6 个节点（3 主 3 从），且结尾加
--cluster-replicas 1
真正麻烦的从来不是报错本身，而是 nodes.conf 里那一行静态 IP —— 它不会自动更新，也不会告诉你哪里错了，只默默让整个集群变成一座孤岛。
