当 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 能更快定位并解决问题。
