哨兵启动后找不到主从节点的根本原因是其自动广播的 announce-ip 为内网地址（如172.18.0.3），在Docker、云主机或NAT环境中对外不可达；必须显式配置 sentinel announce-ip 和 announce-port 为外部可连通的IP与端口，并确保 bind、防火墙、安全组等配套正确。
为什么哨兵启动后找不到主节点或从节点？
根本原因往往是容器、云主机或NAT网络下，哨兵自动发现的 sentinel announce-ip 是内网地址（比如 172.18.0.3），而其他哨兵或客户端尝试用这个地址去连，结果连不通。它不是配置错了，而是 Redis 哨兵默认“自报家门”时用了本机 bind 接口的 IP，而这个 IP 在云环境里对外不可达。
必须显式设置 sentinel announce-ip 和 sentinel announce-port
只要部署在 Docker、K8s、阿里云/腾讯云 VPC 或任何带 NAT/安全组的环境里，就必须手动指定对外可访问的地址。否则哨兵之间互相写入的节点地址是错的，故障转移会失败，客户端也拿不到正确的主节点地址。
-
sentinel announce-ip必须填客户端和其它哨兵能直接 TCP 连通的 IP（如公网 EIP、SLB 后的真实私网 VIP、或 Kubernetes Service 的 ClusterIP + headless 配合 DNS） -
sentinel announce-port要与哨兵实际监听的端口一致（默认26379），如果做了端口映射（如 Docker -p 26380:26379），这里就得填26380 - 这两个配置必须写在哨兵配置文件中，或通过
redis-sentinel /path/to/sentinel.conf启动前就生效，运行时CONFIG SET不支持修改
常见错误场景与验证方式
即使配了 announce-ip，也可能因以下原因失效：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 配置文件里写了
bind 127.0.0.1却没放开监听外网接口 → 哨兵进程本身收不到其它节点发来的命令，要加bind 0.0.0.0或具体网卡 IP - 云安全组/防火墙没放行
sentinel announce-port（不是 Redis 端口！是哨兵端口），导致 TCP 握手失败 - 执行
SENTINEL MASTER mymaster查看返回结果中的ip字段，确认是否为预期的对外地址；再用telnet <该ip> <announce-port>手动测试连通性 - Docker 场景下误用
localhost或127.0.0.1作为announce-ip→ 容器间网络隔离，彼此看不到对方的 localhost
不同环境下的典型配置示例
以三节点哨兵为例（mymaster 主节点已运行在 10.0.1.10:6379）：
port 26379 dir "/tmp" sentinel monitor mymaster 10.0.1.10 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 sentinel announce-ip 47.98.123.45 # ← 公网 IP，或 SLB 后的真实服务 IP sentinel announce-port 26379 bind 0.0.0.0 protected-mode no
在 Kubernetes 中，若用 headless Service + StatefulSet，announce-ip 可设为 Pod DNS 名（如 sentinel-0.sentinel-headless.default.svc.cluster.local），但前提是客户端和哨兵都支持 DNS 解析且超时容忍足够 —— 实际更稳的方式仍是配合 hostNetwork: true 或使用 NodePort + status.hostIP 注入。
真正麻烦的从来不是加两行配置，而是改完之后没人去 telnet 验证那条连接通不通。
