Redis集群总线端口默认为客户端端口加10000，如6379→16379；可通过cluster-port显式配置，否则自动计算；必须唯一、可达且防火墙/安全组/Docker需放行该端口。
集群总线端口怎么算出来的
Redis 集群的内部通信（Gossip 协议、故障检测、配置更新）不走客户端端口，而是用一个独立的「集群总线端口」，它默认 = port + 10000。比如你配了 port 6379，那总线端口就是 16379；配了 port 7000，总线就是 17000。
这个偏移值不是硬编码在源码里不可改的，而是由配置项 cluster-port 控制——但注意：它只在你**显式设置时生效**，否则就走默认逻辑。
-
cluster-port是可选配置，不写就自动按port + 10000算 - 如果你写了
cluster-port 18000，那无论port是多少，总线都固定用18000 - 总线端口必须和客户端端口在同一台机器上，且不能被其他进程占用
为什么连不上集群？大概率是总线端口没放开
常见错误现象：CLUSTER NODES 返回的节点列表里，很多节点状态是 fail 或显示 connect timeout；redis-cli --cluster check 报 Node XXX is not reachable；日志里反复出现 Unable to connect to MASTER 或 connect: Connection refused。
根本原因往往不是客户端端口（如 6379）没通，而是总线端口（如 16379）被防火墙/安全组/Docker 网络策略拦住了。
- Linux 上检查：
ss -tlnp | grep :16379（确认 Redis 进程确实在监听） - 云服务器务必检查安全组规则：要放行总线端口，不只是客户端端口
- Docker 启动时得显式映射总线端口：
-p 6379:6379 -p 16379:16379，否则容器内能通，外部节点连不上 - Kubernetes 中，Service 必须为总线端口单独定义一个
targetPort，不能复用 client port 的 Service
cluster-port 和 port 的配置顺序有影响吗
没有。Redis 启动时会先读取 port，再判断是否设置了 cluster-port；如果没设，就现场计算 port + 10000。所以顺序无关紧要，但要注意：两个值不能冲突，也不能超出端口范围（0–65535）。
- 如果
port 65530，默认总线端口会是65530 + 10000 = 75530→ 超出合法范围 → Redis 启动失败，报错Invalid port number - 此时必须显式配置
cluster-port，比如cluster-port 16379 -
cluster-port值必须是整数，不能带协议或 host，也不能是域名
多个实例跑在同一台机器上，端口偏移还安全吗
不安全——这是最容易踩的坑。比如你起三个节点：6379、6380、6381，按默认规则，它们的总线端口分别是 16379、16380、16381。看起来不重叠，但前提是这些端口全空着。
现实中，16379 很可能已被某个旧服务、监控 agent 或 Docker 容器占用了。Redis 不会自动跳过冲突端口，而是直接启动失败，日志里只有模糊提示：Failed to bind to port。
- 启动前务必手动检查：
lsof -i :16379或netstat -tuln | grep :16379 - 开发/测试环境建议统一避开默认偏移，比如全部用
cluster-port 20000起始，然后 +0/+1/+2 - 生产环境强烈建议用
cluster-port显式声明，别依赖自动计算，避免上线时因端口冲突卡住
偏移值本身只是个约定，真正关键的是每个节点的总线端口必须唯一、可达、且配置一致——集群握手阶段对不上端口，后面所有操作都是空中楼阁。
