根本原因是集群总线端口未开放：redis集群需同时开放客户端端口（如6379）和集群总线端口（客户端端口+10000，如16379），二者缺一不可，否则节点间无法通过gossip协议通信，导致“waiting for the cluster to join”卡住。
redis-cli --cluster create 卡在 Waiting for the cluster to join
根本不是配置写错了，也不是节点没起来，而是集群总线端口压根没通。Redis 集群靠 Gossip 协议同步状态，走的是 16379（默认端口偏移量 +10000），不是你 telnet 得通的 6379。
常见误判：
• 只测了 telnet 192.168.5.20 6379，没测 16379
• 在云平台只开了安全组的 6379，漏掉 16379
• 用 ping 看网络层通断，但 ICMP 不代表 16379 TCP 端口可达
实操建议：
• 执行 redis-cli -p 6379 cluster nodes 找出异常节点 IP 和端口（如 192.168.5.20:6379）
• 从其他任一正常节点执行：telnet 192.168.5.20 16379（Linux/macOS）或 Test-NetConnection 192.168.5.20 -Port 16379（Windows）
• 不通就直接查防火墙和安全组，别翻 Redis 日志
firewalld 必须成对开放客户端端口与集群总线端口
如果你用 --port 7001 启动节点，总线端口就是 17001；用 --port 7002，就是 17002——不是固定值，不能只开 6379 和 16379 就万事大吉。
firewalld 正确操作：
• 每个节点的两个端口都得显式添加：firewall-cmd --permanent --add-port=7001/tcp 和 firewall-cmd --permanent --add-port=17001/tcp
• 多节点部署（如 7002/7003）必须逐个配 17002/17003，没有批量捷径
• 执行 firewall-cmd --reload 后，用 firewall-cmd --list-ports 确认是否真加进去了
注意：ss -tlnp | grep :7001 要能看见 Redis 进程在监听，否则防火墙开了也没用。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
云服务器安全组优先级高于本地防火墙
哪怕 firewall-cmd 放通了，阿里云/AWS/Tencent 安全组没开 17001，照样失败。这是最常被跳过的环节。
安全组配置要点：
• 入方向规则里，7001 和 17001 必须同时存在，协议选 TCP
• 源地址填集群内所有节点的私网 IP 段（如 192.168.0.0/16），别填 0.0.0.0/0
• 修改后规则几秒内生效，但别立刻重试，先用 nc -zv 192.168.131.135 17001 验证连通性
企业内网还可能有微隔离网关拦截非标端口，16379 就算“非标”，得单独报备开通。
protected-mode no 和 bind 配置冲突导致集群发现失败
这两个配置经常一起出问题：
• protected-mode yes 会强制拒绝非本地连接，哪怕你写了 bind 0.0.0.0
• bind 127.0.0.1 直接让其他节点连不上本机任何端口（包括 16379）
集群模式下推荐组合：
• protected-mode no
• bind 0.0.0.0 或明确指定监听 IP（如 bind 192.168.5.20）
• 再配合防火墙或安全组做访问控制，而不是靠 bind 锁死
如果用了 cluster-announce-ip，确保所有节点该值一致，且是其他节点能路由到的地址——这个细节一旦错，cluster nodes 里看到的 IP 就是错的，连对端口也白搭。
