修复Redis集群Bad response错误：检查节点间总线端口是否开启

当 Redis 集群抛出 "Bad response from node" 错误时，许多运维人员首先会检查 6379 端口，但真正的瓶颈往往隐藏在集群总线端口——默认端口为 16379（即业务端口加10000）。该端口专用于节点间的 Gossip 通信，包括节点握手、心跳监测、故障检测及槽迁移等操作，而 6379 仅负责处理客户端请求。换句话说，6379 端口连通并不代表集群能正常运行，总线端口不通才是导致节点无法互相识别、返回 fail 或 noaddr 等错误的根本原因。

为何故障根源在集群总线端口而非 6379？

Redis 集群节点之间使用两套独立的通信通道：

• 6379（或自定义业务端口）负责处理客户端命令请求——该端口通畅不代表集群功能正常；
• 16379（即业务端口加10000）作为集群总线端口，专门处理节点间握手、心跳、故障检测及槽迁移等操作——若 CLUSTER NODES 命令返回 fail 或 noaddr，或者出现 Bad response from node，问题多出在此端口；
• 总线通信采用二进制私有协议，无法通过 telnet 或 curl 验证，必须使用 redis-cli --cluster 或直接连接总线端口发送 PING 命令。

如何快速检测 16379 端口是否真正开启并可访问？

不要只在本地执行 netstat -tuln | grep 16379——那只能说明自身已监听，关键是从其他节点发起连接测试：

• 在节点 A 上运行命令：redis-cli -h <目标IP> -p 16379 ping——若返回 PONG，表明总线端口可达且服务正常；若超时或提示 Connection refused，则说明目标节点未监听或防火墙拦截。
• 确认目标节点配置是否已启用集群模式：执行 grep "cluster-enabled yes" /etc/redis/6379.conf，若未找到该行或值为 no，则 16379 端口不会启动。
• 检查 bind 地址是否被限定为 127.0.0.1：执行 grep "^bind" /etc/redis/6379.conf，配置应包含实际网卡 IP 或 0.0.0.0（生产环境中不推荐后者）。
• Linux 防火墙常遗漏此端口：运行 iptables -L INPUT -n | grep 16379 检查，若无匹配，需添加规则：iptables -A INPUT -p tcp --dport 16379 -j ACCEPT。

常见但易被忽视的陷阱及排查方法

即使所有节点都已开启 16379，仍可能因以下原因导致 "Bad response"：

• 节点间系统时间差异超过 5 秒——集群会拒绝通信。使用 ntpq -p 或 timedatectl status 查看时间状态并同步。
• SELinux 处于启用状态但未放行端口：执行 sestatus 查看状态，临时关闭测试可运行 setenforce 0。
• 配置中设置了 cluster-announce-ip 但填写的是内网 IP，而节点实际通过公网通信——这会导致其他节点尝试连接错误的 IP 地址。
• 某个节点的 cluster-config-file 被多个实例共用（例如未按端口区分文件名），造成节点元数据混乱，重启后错误依然存在。

总线端口问题通常隐蔽性强：它不会在日志中报错，也不影响单点访问，但会导致集群视图分裂、槽信息不一致、重定向失败。因此，一旦遇到 "Bad response from node"，优先检查 16379 端口的连通性，这比调整配置或重刷 nodes.conf 能更快定位并解决问题。