Redis 6.2 默认不解析主机名，必须显式配置 sentinel resolve-hostnames yes，否则在 Docker/K8s 等 DNS 环境中，哨兵将主机名（如 redis-master）误作 IP 导致连接失败、监控失效、故障转移瘫痪。
Redis 6.2 默认不解析主机名，必须显式启用 sentinel resolve-hostnames yes，否则在 Docker、K8s 或任何依赖 DNS 的环境中，哨兵会把 redis-master 这类主机名当成非法 IP 直接连接失败。
为什么 sentinel resolve-hostnames 在 Redis 6.2 中不是可选而是必需
Redis 6.2 的哨兵默认值仍是 no（即使文档里没强调，源码和实际行为都确认这一点）。这意味着：
- 哨兵读到
sentinel monitor mymaster redis-master 6379 2时，不会查 DNS，而是直接调用inet_aton("redis-master")→ 返回 0 → 解析失败 - 启动日志里会出现明确错误：
Error resolving hostname 'redis-master' - 后续所有监控、主观下线判断、故障转移全部卡住，因为根本连不上主节点
- 这个行为在物理机配固定 IP 时“碰巧”能过，但在容器编排环境里 100% 失败
如何正确配置 sentinel resolve-hostnames（含生效验证）
它必须出现在 sentinel.conf 中，并且要在 sentinel monitor 之前或之后均可，但不能被 CONFIG REWRITE 覆盖掉 —— 因为哨兵重写配置时默认不保留该指令（除非你手动加了）。
正确写法示例：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
port 26379 bind 0.0.0.0 sentinel resolve-hostnames yes # ← 必须这一行 sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 30000
验证是否生效：
- 启动后执行
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster，返回 IP 而非报错 - 查看哨兵日志，确认没有
Error resolving hostname类错误 - 手动触发一次
SENTINEL failover mymaster，观察是否能成功解析新主节点的主机名（比如redis-slave-1）
sentinel resolve-hostnames yes 的副作用与边界条件
开启后不是“一劳永逸”，它只解决 DNS 解析环节，其他依赖仍需对齐：
- Docker Compose 中必须保证哨兵容器和 Redis 容器在同一个自定义网络（
network_mode: bridge不行，得用networks: [redis-net]） - Kubernetes 中，Service 名称必须能被 Pod 内 DNS 正确解析（即
redis-master.redis.svc.cluster.local能通），哨兵不自动补全域名后缀 - 如果主机名解析结果是 IPv6 地址，而 Redis 实例只监听 IPv4，仍会连接失败 —— 此时需要配合
bind或replica-announce-ip控制暴露地址族 -
sentinel announce-hostnames yes是另一个开关，仅影响哨兵对外广播自己地址的方式，和解析无关，别混淆
最常被忽略的一点：Redis 6.2 的哨兵在首次解析成功后，会缓存 DNS 结果，但不会定期刷新。如果后端服务 IP 变了（比如 K8s Pod 重建），哨兵不会自动感知，直到下次故障转移或重启 —— 这时候光开 resolve-hostnames 不够，还得靠合理的 down-after-milliseconds 和健康探测兜底。
