单纯靠protected-mode或requirepass无法防护Redis集群，因二者均不作用于集群总线端口（如16379），该端口明文通信且无认证；真正有效的防线是绑定内网IP、配置cluster-announce-ip及严格限制防火墙仅允内网访问6379/16379端口。
单纯靠 protected-mode 或只设一个 requirepass，根本防不住 Redis 集群被扫描或入侵——集群总线端口（如 16379）不认密码，protected-mode 在集群模式下默认失效，这是绝大多数人踩坑的起点。
为什么集群里 protected-mode yes 几乎没用
protected-mode 的激活条件极其苛刻：必须同时满足 protected-mode yes、未配置 bind、且未设置 requirepass。而集群部署时，你必然要配 bind（否则节点间无法通信），也必然要设 requirepass（否则客户端连不上）。这两个动作一做，protected-mode 就自动退场，不再拦截任何连接。
更关键的是，protected-mode 只作用于客户端端口（如 6379），对集群总线端口（16379）完全无感知。攻击者只要扫到 16379 端口，就能发 CLUSTER NODES、伪造心跳、甚至触发故障转移。
所以别依赖它挡扫描——它不是防火墙，只是个“新手提醒开关”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
集群中 requirepass 的真实作用范围与陷阱
requirepass 只校验客户端连接端口（6379），不保护集群总线（16379）。这意味着：
- 即使所有节点都配了相同
requirepass，攻击者直连16379仍可执行任意集群命令 - 若某节点
requirepass配错或漏配，CLUSTER NODES会显示noauth或fail，导致槽分配失败 - 密码含
$、@、#等 shell 特殊字符时，命令行启动 Redis 会解析错误，实际生效的密码可能被截断 - 配置文件中写法必须是
requirepass YourPassw0rd2026!，前后不能加引号；加引号 = 密码字面值带引号
真正能阻断外部扫描的三道硬防线
集群安全不靠“设个密码就完事”，得从网络层、绑定层、运行层同步卡死：
- 所有节点的
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<br>sudo iptables -A INPUT -p tcp --dport 16379 -s 10.0.1.0/24 -j ACCEPT<br>sudo iptables -A INPUT -p tcp --dport 6379 -j DROP<br>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 配置缺失，这两项出问题，再强的密码也形同虚设。
