bind不能设为0.0.0.0，否则集群通信端口暴露，易遭CLUSTER MEET攻击、槽位篡改；必须绑定内网IP且与cluster-announce-ip严格一致，并保持protected-mode yes。
bind参数在Redis集群中为什么不能设为0.0.0.0
直接设 bind 0.0.0.0 会让所有节点的 Redis 实例监听公网（或宿主机所有网卡），集群通信端口（如 redis-cli --cluster 用到的 6379 + 10000）一旦暴露，攻击者可伪造 CLUSTER MEET 请求、篡改槽位映射，甚至接管整个集群。这不是理论风险——真实环境中已有因 bind 配置不当导致槽位被恶意迁移的案例。
正确做法是只绑定集群内部通信所用的内网网卡 IP，且该 IP 必须与 cluster-announce-ip 一致。否则节点间握手失败，CLUSTER NODES 显示 ip:port 不可达，日志里反复出现 Unable to connect to MASTER 或 connect timeout。
如何查出集群节点该 bind 哪个 IP
不能凭感觉写内网段（比如硬写 192.168.1.10），必须确认每个节点实际用于集群通信的网卡出口 IP：
- 登录节点执行
ip -4 route get 1 | awk '{print $7}'（获取默认路由出口 IPv4 地址） - 或运行
hostname -I | awk '{print $1}'（取第一个非 loopback 的 IPv4） - 若用 Docker/K8s，需看容器网络配置：Docker 桥接模式下通常用
docker network inspect bridge | grep Gateway；K8s 则看 Pod 的status.podIP
拿到这个 IP 后，bind 和 cluster-announce-ip 必须严格一致，否则节点注册到其他节点的地址不可达。
Redis 6+ 的 protected-mode 与 bind 的联动关系
Redis 6 默认开启 protected-mode yes，它会在以下任一条件满足时拒绝外部连接：
– 未配置 bind
– bind 只含 127.0.0.1 且无密码
– bind 是 0.0.0.0 但没设 requirepass
集群场景下，常见错误是关掉 protected-mode 来“绕过” bind 限制，这等于放弃最后一道防护。正确解法是：
– 显式设置 bind 为内网 IP
– 保持 protected-mode yes
– 若需跨主机管理，走跳板机或 SSH 端口转发，不开放管理端口到公网
配置示例与验证要点
假设某节点内网 IP 是 10.10.20.5，对应 redis.conf 片段应为：
bind 10.10.20.5 protected-mode yes port 6379 cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 5000 cluster-announce-ip 10.10.20.5 cluster-announce-port 6379 cluster-announce-bus-port 16379
启动后立即验证：
– redis-cli -h 10.10.20.5 cluster nodes | head -3 看是否包含本节点且状态为 myself,master
– 从另一节点执行 redis-cli -h 10.10.20.5 ping，应返回 PONG（说明 bind 生效且未被防火墙拦截）
– 在本机外网 IP 上 telnet 测试 telnet 公网IP 6379，应连接超时或被拒（验证未暴露）
最容易被忽略的是 cluster-announce-bus-port：它默认是 port + 10000，但如果节点防火墙只放行了 6379 和 16379，而你没显式声明 cluster-announce-bus-port，其他节点会尝试连错端口，导致握手卡住——这个细节在官方文档里藏得深，但线上集群故障里高频出现。
