Redis集群启动失败、节点无法握手、CLUSTER NODES显示fail或connecting，大概率是Bus端口（client port+10000）被占用；需确保各节点client port与其对应bus端口区间互不重叠，如7000→17000，则下一节点client port至少为17001。
Redis 集群启动失败、节点无法握手、CLUSTER NODES 显示 fail 或一直 connecting，大概率是端口冲突——尤其是 Bus 端口（非客户端端口）被占用了。
为什么 Redis 集群要额外开 Bus 端口？
Redis 集群节点之间用两种通信通道：tcp（客户端连接和部分命令）和 bus（集群内部心跳、故障检测、配置更新）。Bus 不复用 client port，而是默认在 client port 基础上 +10000。比如 redis-server --port 7000，它自动监听 17000 作为 bus 端口。
这个机制很隐蔽，但一旦多个实例的 client port 接近（如 6999 和 7000），它们的 bus 端口就会撞车（16999 和 17000 → 重叠或相邻冲突）；或者你手动启了其他服务占了 17000，redis-server 不报错，但集群发现不了彼此。
- Bus 端口不支持自定义名或复用，只能靠规划 client port 来间接控制
- 检查是否启用：启动后执行
redis-cli -p 7000 cluster nodes，若返回空或只有自己且状态为noaddr，优先查17000是否被占用 -
netstat -tuln | grep :17000或lsof -i :17000是最直接的验证方式
如何安全规划 client port 以避开 bus 冲突？
核心原则：确保任意两个节点的 client_port 与 client_port + 10000 区间互不重叠。例如 7000 占用 7000–7000（client）和 17000–17000（bus），那下一个节点 client port 至少得 ≥ 17001，否则 bus 端口会和前者的 client port 撞上。
- 推荐方案：所有节点 client port 设为
7000, 7001, 7002, 7003, 7004, 7005—— 它们的 bus 端口分别是17000–17005，互不干扰，且远离常用端口段 - 危险组合：不要用
6999和7000同时部署，因为6999+10000=16999，和7000的 client port 就只差 1，某些内核或防火墙策略下仍可能误判为冲突 - 如果机器资源紧张，必须压缩端口范围，可改用
8000, 8001, 8002（bus 为18000–18002），避开10000–12000这类常被 Docker/VM 占用的区间
启动时怎么确认 bus 端口已正确监听？
不能只看 redis-server 日志里有没有 “Ready to accept connections”，还要验证 bus 端口是否真在 LISTEN 状态。Redis 启动成功后，bus 端口必须出现在 netstat 输出中，且进程 PID 和 redis 实例一致。
- 启动命令后立刻执行：
ss -tlnp | grep $(pgrep -f "redis-server.*7000")，应看到两行：一行:7000，一行:17000 - 如果只看到 client port，说明 bus 初始化失败——常见原因是
bind配置错误（如bind 127.0.0.1但 bus 默认尝试 bind 所有接口），此时需显式设置cluster-announce-ip和cluster-announce-port - 日志里搜
"Failed to join the cluster"或"Unable to send PING"，基本指向 bus 通路不通，不是网络问题就是端口没起来
Bus 端口不像 client port 那样暴露在配置文件里，容易被当成“内部细节”忽略。但集群能否形成、故障转移是否及时，全依赖它。规划时多算一步 +10000，比上线后抓包查 MEET 请求超时省力得多。
