如何防范Redis集群被外部网络非法扫描_通过配置protected-mode与复杂requirepass

单纯靠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、伪造心跳、甚至触发故障转移。

所以别依赖它挡扫描——它不是防火墙，只是个“新手提醒开关”。

集群中 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 配置缺失，这两项出问题，再强的密码也形同虚设。