不少人在第一次搭建Redis集群的时候都会遇到一个奇怪的坑：明明六个节点的服务端口都开得好好的，cluster meet命令也执行成功了，可集群状态就是迟迟达不到ok，日志里反复刷着Node断开连接的消息。这时候问题十有八九不在服务端口上，而是出在另一个默认隐藏起来的端口——集群总线端口，也就是我们常说的cluster-bus-port。这个端口不监听客户端请求，专门负责节点之间的内部通信，一旦被占用或者被防火墙拦掉，整个集群就会陷入莫名其妙的握手失败。
一、cluster-bus-port到底是什么
Redis集群模式下的每个节点，实际上会打开两个TCP端口。第一个是我们熟悉的服务端口，比如默认的6379，用来接收客户端命令、处理读写请求。第二个就是集群总线端口，它的默认值是服务端口加上10000，也就是说如果你的服务端口是6379，那么总线端口就是16379。
集群总线是节点之间的内部数据通道，负责的事情相当多：心跳检测、故障探测、Gossip协议的消息传播、配置信息的交换、主从切换时的投票协商等等。这些通信完全不走服务端口，而是通过总线端口建立一个二进制协议的专用连接。换句话说，服务端口只管对外的业务，总线端口只管节点之间的内部协调，两条通道各司其互。
正因为总线端口的存在感比较低，很多人在配置防火墙或者做端口规划的时候只开放了服务端口，结果节点之间互相发现不了对方，日志中出现大量connection refused或者无法连接16379之类的报错。理解了双端口机制，这类问题的排查思路就非常清晰了。
二、如何查看和修改cluster-bus-port配置
在默认情况下，你不需要显式配置这个参数，Redis会自动按照服务端口加10000的规则计算总线端口。比如你在配置文件里写了port 7000，那么总线端口自动就是17000。但在某些场景下，比如宿主机端口映射、容器编排环境，或者公司防火墙只放行了特定端口段，你就需要手动指定总线端口了。
在redis.conf中显式配置的写法如下：
# 服务端口 port 7000 # 显式指定集群总线端口，默认为服务端口 + 10000 cluster-port 17000 # 开启集群模式 cluster-enabled yes cluster-config-file nodes-7000.conf cluster-node-timeout 15000
需要注意的是，不同版本对这个配置项的叫法略有差异。在Redis 7.0及之后的版本中，配置项的正式名称是cluster-port；在旧版本文档和社区讨论中，人们习惯用cluster-bus-port来称呼它，但旧版本并没有提供单独配置的参数，总线端口始终是服务端口加10000。所以在使用之前，建议先用redis-server --version确认自己的版本，避免配置了不生效的参数。
还有一个容易踩坑的地方：总线端口不能和服务端口相同，也不能和其他节点的任何端口冲突。Redis在启动时会做校验，如果发现cluster-port和port相等，会直接拒绝启动并抛出配置错误。因此在做端口规划时，最好画一张表把每个节点的两个端口都列清楚，比如7000对应17000、7001对应17001，一目了然。
三、Windows环境下排查总线端口问题
如果你是在Windows服务器上运行Redis集群（比如通过移植版Redis或者WSL环境），排查端口问题的第一步就是确认端口是否处于监听状态。打开命令提示符，执行以下命令：
netstat -ano | findstr "16379"
如果能看到LISTENING状态的记录，说明节点已经成功监听了总线端口；如果什么都没有输出，说明Redis没有启动或者总线端口配置有问题，需要回头检查配置文件。netstat输出结果的最后一列是占用该端口的进程ID，可以用tasklist | findstr "进程ID"确认对应的进程是不是redis-server，防止其他程序抢占了端口。
如果端口被其他程序占用了，有两种解决方式：要么结束占用端口的进程，要么修改Redis的cluster-port配置换一个空闲端口。在Windows环境下修改防火墙规则同样重要，可以在控制面板的高级安全Windows防火墙中新增入站规则，放行对应的TCP端口段；也可以用管理员权限的PowerShell命令快速操作：
New-NetFirewallRule -DisplayName "Redis Cluster Bus" -Direction Inbound -Protocol TCP -LocalPort 17000-17005 -Action Allow
执行完毕后，集群节点之间的Gossip通信就能正常建立了。如果你是在Docker容器里跑Redis集群，还要注意容器端口映射必须同时映射服务端口和总线端口两个端口，只映射一个端口是集群搭建失败的最常见原因。映射关系可以这样写：宿主机的17000对应容器的17000，宿主机的7000对应容器的7000，两个都不能少。
四、集群通信异常的典型表现与验证方法
总线端口出问题时，集群并不会直接报配置错误，而是表现为一种慢性的、难以定位的故障。典型的症状包括：cluster info命令显示cluster_state:fail、节点之间互相标记为PFAIL状态、执行cluster nodes时看到大量disconnected标记、主从复制时而正常时而中断。
验证总线通信是否正常，可以借助cluster nodes的输出来判断。每个节点记录的集群拓扑中，其他节点的地址和端口都在列表里。如果某个节点始终无法与其他节点建立连接，可以在该节点所在机器上用telnet或者PowerShell的Test-NetConnection命令测试总线端口的连通性：
Test-NetConnection -ComputerName 192.168.1.10 -Port 17000
返回的TcpTestSucceeded字段如果是True，说明网络层没问题，故障可能出在Redis配置本身；如果是False，那就重点排查防火墙、安全组策略以及端口是否真的在监听。按照服务端口、总线端口、防火墙这三步依次排查，绝大多数集群通信故障都能在短时间内定位解决。
总的来说，cluster-bus-port虽然只是一个小小的配置细节，却是Redis集群能否正常运转的关键一环。端口规划阶段就把服务端口和总线端口一起纳入管理，能为后续的运维省去很多麻烦。
Redis集群cluster-bus-port总线端口修改时间：2026-09-11 06:40:31