根本原因是redis从节点默认用内网ip（如172.18.0.5）向哨兵上报地址，导致sentinel sentinels返回不可达ip；必须配置replica-announce-ip和replica-announce-port指定对外可达的ip与端口，并重启从节点生效。
SENTINEL SENTINELS 返回的从节点 IP 是 172.x.x.x，客户端连不上
根本原因不是哨兵配错了，而是 Redis 从节点自己“报错身份”：它默认用 bind 地址或本地网卡 IP（如 172.18.0.5）向哨兵上报自己的位置。哨兵信了，就存下来、广播出去，客户端一拿就踩坑。
必须让每个从节点明确告诉哨兵：“我对外可连的地址是这个”，靠的就是 replica-announce-ip 和 replica-announce-port 这两个配置项。
-
replica-announce-ip填客户端能直接 TCP 连通的 IP，比如云主机的私网 VIP、SLB 后的真实 IP、或 Kubernetes 中 Service 可解析的 ClusterIP -
replica-announce-port必须和该从节点实际监听的 Redis 端口一致（如6380），不能写成宿主机映射端口（Docker-p 6380:6379时，这里仍填6379） - 这两个参数只在从节点的
redis.conf里生效，CONFIG SET不支持运行时修改 - 改完后需重启从节点，否则哨兵缓存的旧地址不会自动刷新
配了 replica-announce-ip 却没生效？检查这三处
常见现象是配置写了，但 SENTINEL SENTINELS mymaster 或 INFO replication 里看到的仍是内网 IP —— 多半是被其他配置覆盖或未触发重载。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 确认从节点确实是作为 replica 启动的：
redis-server /path/to/redis.conf，且配置中含replicaof指令；若误用redis-sentinel启动，该参数会被忽略 - 检查是否同时设置了
bind：如果bind 127.0.0.1且没放开外网监听，从节点收不到哨兵发来的REPLICAOF指令，也就不会触发 announce 流程 - 验证是否被
protected-mode yes拦截：该模式下若未设密码、未指定 bind IP，Redis 会拒绝外部连接，导致哨兵无法与从节点完成握手，announce 信息根本不会被采集
哨兵拿到错误 IP 后，故障转移会失败吗？
会，而且很隐蔽。哨兵选主时，会基于 replica-announce-ip 决定把哪个从节点提升为主 —— 如果这个 IP 不可达，新主节点虽然角色变了，但客户端仍连不上，表现为：
- 客户端通过
SENTINEL GET-MASTER-ADDR-BY-NAME mymaster拿到的是不可达地址，连接超时 - 原主节点恢复后，因新主地址不可达，无法正常回切或同步
- 日志里反复出现
Unable to connect to MASTER或Connection refused，但redis-cli -h手动测又通——说明问题出在“被广播的地址”而非服务本身
replica-announce-ip 和 sentinel announce-ip 的关系
它们管不同层，但必须协同：
-
sentinel announce-ip控制哨兵自己“怎么被别人找到”，影响SENTINEL SENTINELS返回的哨兵列表中的 IP -
replica-announce-ip控制从节点“怎么被哨兵找到”，影响SENTINEL SLAVES mymaster和故障转移时的候选名单 - 两者都必须填真实可达地址，且不能互相冲突：比如哨兵填了公网 IP，但从节点还填内网 IP，客户端拿到主节点地址后，可能连得上哨兵却连不上主节点
- 如果环境支持 DNS，可配合
announce-hostnames yes统一用域名，但要注意客户端 SDK 是否兼容（如 Lettuce 默认解析 IP，不自动重试域名）
SENTINEL RESET mymaster → 等 30 秒 → 查 SENTINEL SLAVES mymaster 输出里的 ip 字段。只要这里对了，后续所有流程才真正可控。
