为什么Redis集群节点经常出现Connection Refused报错_检查cluster-announce-ip配置是否正确-Redis-PHP中文网

“connection refused”本质是tcp连接建立失败，表明目标ip:port无监听进程，非集群逻辑问题；高频源于docker/k8s环境下cluster-announce-ip未显式配置或配置错误，导致客户端重定向至不可达内网ip。

为什么redis集群节点经常出现connection refused报错_检查cluster-announce-ip配置是否正确

“Connection refused”错误在 Redis 集群中高频出现，但很多人误以为是集群没搭好、节点没握手成功。实际上，只要 cluster nodes 能返回完整节点列表（哪怕状态是 fail），就说明集群协议层已运行——此时报错几乎全是网络层或地址宣告层的问题。

典型表现是：客户端能连上第一个节点（比如 192.168.1.10:7001），但收到 MOVED 12345 172.18.0.11:7001 后立刻失败，因为 172.18.0.11 是容器内网 IP，本地或客户端根本路由不到。

不要先查 redis-cli -c 是否能执行命令——它会自动重试、掩盖真实连接路径
用 redis-cli -h 172.18.0.11 -p 7001 ping 直接测目标节点地址，才能暴露真实不可达性
如果 cluster nodes 输出里大量节点 IP 是 127.0.0.1 或 172.x.x.x，基本可锁定为 cluster-announce-ip 缺失或写错

Redis 默认不主动宣告自己对外可见的 IP，而是从 bind 或系统接口自动推导——这在 Docker/K8s 环境下必然出错。你不能依赖“它自己会选对”，必须强制指定。

正确配置方式（加在每个节点的 redis.conf 中）：

cluster-announce-ip 192.168.1.10
cluster-announce-port 7001
cluster-announce-bus-port 17001

cluster-announce-ip 填的是客户端（如 Jedis、ARDM、IDEA）所在机器能直接访问的 IP，不是容器 IP，也不是 0.0.0.0
cluster-announce-port 必须和该节点实际监听的客户端端口一致（即 port 配置值），不能照抄模板里的 ${PORT} 占位符
cluster-announce-bus-port = 客户端端口 + 10000，必须和集群总线端口严格对应；若用 iptables 或安全组，这个端口也得放行
改完配置后必须重启 Redis 进程（kill -SIGUSR2 不生效），并确认 nodes.conf 被重写——旧文件残留会导致节点仍广播错误地址

即使写了 cluster-announce-ip，仍可能因以下原因失效：

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

配置写在了错误的 conf 文件里（比如启动时指定了 -f /etc/redis/redis.conf，但你改的是 /opt/redis/redis.conf）
用了 Docker，但 cluster-announce-ip 写成了宿主机的 127.0.0.1 或未映射的内网地址
多个节点配置了相同的 cluster-announce-ip（比如全写成 192.168.1.10），导致集群认为所有节点都在同一台机器上
云服务器开了多网卡，cluster-announce-ip 填的是私有网段 IP，但客户端走公网访问，中间 NAT 未做端口映射

验证是否生效最直接的方式：

在任意节点执行：redis-cli -p 7001 cluster nodes | grep -v "myself" | awk '{print $2}' | sort -u

输出的每行 IP 都应是你手动配置的 cluster-announce-ip，而不是容器 IP、127.0.0.1 或自动识别的网卡地址。

只开客户端端口（如 7001）而不开集群总线端口（如 17001），会导致节点间 gossip 失败，继而触发频繁的 fail 状态切换——这时你看到的 “Connection refused” 往往是集群内部重定向失败引发的连锁反应，而非客户端直连问题。

Linux 上检查：sudo ss -tlnp | grep ':17001'，确认 Redis 进程确实在监听该端口
iptables 规则必须包含：iptables -A INPUT -p tcp --dport 17001 -j ACCEPT
云平台安全组需额外添加一条入方向规则：端口 17001，协议 TCP，源 IP 为其他 Redis 节点的可访问地址（非 0.0.0.0/0）
Kubernetes 中若用 hostNetwork: true，要确保宿主机防火墙也放行；若用 Service 暴露，则需为每个节点单独建 Headless Service 并配置 cluster-announce-ip 为 Service 域名（不推荐，易出 DNS 解析问题）

真正麻烦的从来不是配置几行参数，而是改完之后没验证 cluster nodes 输出是否更新、没确认总线端口是否可达、也没用客户端直连目标 IP 测试——这些动作漏掉任何一环，都会让问题看起来像“玄学故障”。