很多运维人员认为，只要开启 protected-mode yes 并设置一个复杂的 requirepass 密码，Redis 集群就安全了。然而，这种配置在集群环境下其实只是一种“心理安慰”——因为集群总线端口（默认 16379）既不验证密码，也不受 protected-mode 保护，这才是真正的安全隐患。
让我们揭示一个事实：在集群模式下，protected-mode yes 几乎不会真正生效。它的激活条件非常严格——必须同时满足三个前提：protected-mode yes、未设置 bind、未设置 requirepass。但在生产集群中，你既需要配置 bind（否则节点间无法正常通信），也必须设置 requirepass（否则客户端无法连接）。一旦配置了 bind 和 requirepass，protected-mode 就会自动失效，形同虚设。
更为关键的是，protected-mode 仅对客户端端口（如 6379）有效，对集群总线端口（16379）毫无作用。攻击者一旦扫描到 16379 端口，就可以直接发送 CLUSTER NODES 命令，伪造心跳消息，甚至触发故障转移。因此，protected-mode 本质上只是一个“新手提醒”开关，并非真正的防火墙。
requirepass的真实作用范围与陷阱
requirepass 同样仅对客户端连接端口（6379）进行密码校验，不会保护集群总线（16379）。这意味着什么呢？
- 即使所有节点都配置了相同的
requirepass，攻击者直接连接 16379 端口依然可以执行集群命令，例如获取节点拓扑信息。 - 如果某个节点的
requirepass配置错误或遗漏，执行CLUSTER NODES时会显示noauth或fail，导致槽分配失败，整个集群直接瘫痪。 - 密码中如果包含
$、@、#等 Shell 特殊字符，在命令行启动 Redis 时可能会被解析错误，实际生效的密码可能被截断——不少运维人员曾因此踩坑。 - 配置文件中的密码写法必须是
requirepass YourPassw0rd2026!，前后不能加引号；如果加了引号，密码就会变成带引号的字面值，与预期完全不同。
真正能阻断外部扫描的三道硬防线
集群安全不能仅仅依赖“设置密码”，而必须从网络层、绑定层、运行层同时进行封锁。以下是经过大量生产环境验证的实践步骤：
- 绑定内网IP：所有节点的
redis.conf必须显式指定bind 10.0.1.50（你的内网IP），绝不能留空，更不能使用bind 0.0.0.0或bind ::。 - 显式配置公告地址：必须配置
cluster-announce-ip 10.0.1.50和cluster-announce-port 6379，防止节点向客户端广播公网地址，这是很多人容易忽略的关键细节。 - 防火墙硬性限制：Linux 防火墙（iptables 或 firewalld）必须严格限制 6379 和 16379 端口仅允许内网段访问。示例如下：
sudo iptables -A INPUT -p tcp --dport 6379 -s 10.0.1.0/24 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 16379 -s 10.0.1.0/24 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 6379 -j DROP sudo iptables -A INPUT -p tcp --dport 16379 -j DROP
检查是否真生效的三个命令
配置文件写了不等于起效，上线前必须亲自验证：
- 执行
CONFIG GET bind，确认返回值为具体的内网IP，既不是空值也不是0.0.0.0。 - 执行
CONFIG GET requirepass，确认返回非空字符串，并且与配置文件中的密码一致（注意引号问题）。 - 在另一台非集群节点的机器上，使用
telnet your-redis-ip 16379进行测试——预期应无法连接；如果能够连接，说明防火墙或bind配置尚未生效。
最后，提醒一个最容易忽视的问题：集群总线端口暴露以及 cluster-announce-ip 配置缺失，这两个问题一旦出现，再强的密码也形同虚设。不要让安全防线变成纸老虎。
