redis 7.0 原生集群不支持全局密码认证，各节点必须禁用 requirepass 以保障内部通信；客户端连接需为每个节点单独 auth，或通过代理层统一认证。
Redis 7.0 集群不支持全局密码认证
直接说结论：redis-cli --cluster 创建的原生 Redis Cluster（即 redis-server --cluster-enabled yes 模式）**不支持在集群层面统一设置密码**。你无法像单机 Redis 那样通过 requirepass 让整个集群共用一个密码——每个节点仍需单独配置密码，且客户端必须为每个节点单独认证。
为什么 cluster-enabled 节点不能靠 requirepass 实现“集群密码”
原因很实际：Redis Cluster 的节点间通信（Gossip 协议、failover 协商、slot 迁移）默认走的是无认证的内部连接。如果你给某个节点配了 requirepass，它会拒绝其他节点发来的未带 AUTH 的握手请求，导致集群无法完成握手、状态同步失败，CLUSTER NODES 显示大量 fail 或 noaddr。
常见错误现象包括：
-
Cluster state: fail（redis-cli -p 7001 CLUSTER INFO返回） - 节点日志反复出现
Connection refused或NOAUTH Authentication required -
redis-cli --cluster create卡在 “Waiting for the cluster to join…”
所以，**集群节点之间必须禁用密码认证**（即不设 requirepass），否则集群协议本身就会瘫痪。
可行方案：节点密码 + 客户端显式认证
你仍然可以为每个节点单独启用密码，但必须满足两个前提：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 所有节点配置中，
requirepass值**可以不同**（不强制一致），但每个节点自己的密码要固定 - 所有节点必须关闭
protected-mode yes，并显式绑定地址（如bind 0.0.0.0或具体 IP） - 客户端连接时，必须对每个节点分别执行
AUTH <password></password>；多数语言驱动（如 Python 的redis-py-cluster、Node.js 的ioredis）支持传入password参数自动处理
示例配置节选（每个节点的 /etc/redis/7001.conf）：
port 7001 cluster-enabled yes cluster-config-file nodes-7001.conf cluster-node-timeout 5000 bind 192.168.1.100 protected-mode no # ✅ 可以设密码，但仅用于客户端连接 requirepass node7001-secret2026 # ❌ 不要设 masterauth —— 集群节点间不走 AUTH
启动后，用 redis-cli -p 7001 -a node7001-secret2026 ping 应返回 PONG；但节点间互连不依赖此密码。
真正安全的替代路径：用代理层加认证
如果你需要对外暴露一个带统一密码的“集群入口”，不要试图在 Redis 原生 Cluster 上硬塞认证逻辑。更可靠的做法是：
- 保持所有集群节点无密码（或仅用简单密码防误操作），专注保障内网通信安全
- 在前端加一层带认证的代理，比如
redis-exporter+ Nginx Basic Auth（仅限监控），或更专业的Twemproxy/RedisJSON网关（需自行集成 auth） - 生产环境强烈建议走 TLS + 访问控制：用
stunnel或nginx stream做 SSL 终止，并配合iptables或ufw限制源 IP
注意：redis-server 自身从 7.0 起支持 TLS，但 Cluster 模式下 TLS 配置极其复杂，各节点证书需严格匹配，且官方文档明确标注“TLS in Cluster mode is experimental”。不建议新手在生产环境启用。
最易被忽略的一点：即使你给每个节点都配了密码，只要没关掉 protected-mode 或没正确设置 bind，客户端依然连不上——这个检查比密码本身更容易卡住部署流程。
