redis 7.0哨兵模式中，哨兵节点本身不支持tls监听，主从节点必须配置tls-port、证书及tls-replication yes以强制复制加密，客户端连哨兵后需主动启用tls并校验证书才能确保最终通信加密。
Redis 7.0 哨兵模式必须为每个角色单独配置 TLS：主从节点启用 tls-port 和证书，哨兵节点本身不支持 TLS 监听，但必须通过 tls-replication yes 和 tls-auth-clients yes 强制主从间复制流量走加密通道；客户端连接哨兵时仍用明文，但最终访问主节点时需跳转到 TLS 端口。
主从节点的 redis.conf 必须启用 TLS 复制
哨兵不管 TLS，它只负责发现和切换主从。真正加密发生在主从之间（复制）和客户端直连主从时。所以第一步是让主从节点同时监听普通端口（如 6379）和 TLS 端口（如 6380），并强制复制走 TLS：
-
port 6379（可选保留，仅用于非加密管理连接） -
tls-port 6380（客户端和从节点应优先连这个） tls-cert-file /etc/redis/tls/redis.crttls-key-file /etc/redis/tls/redis.keytls-ca-cert-file /etc/redis/tls/ca.crt-
tls-replication yes（关键！否则从节点仍用明文拉取 RDB/AOF） -
tls-auth-clients yes（拒绝无证书客户端，防止降级）
注意：tls-replication yes 是 Redis 7.0 新增参数，6.x 不支持——没它，哨兵触发故障转移后，新主从之间复制仍是明文。
哨兵节点（sentinel.conf）本身不监听 TLS，但要适配 TLS 主从
Redis 哨兵进程（redis-sentinel）至今（2026 年）不提供 tls-port 或证书配置项。它只能明文监听（如 sentinel-port 26379），但必须能正确识别并转发 TLS 主从的地址：
-
sentinel monitor mymaster 10.0.1.10 6380 2（端口必须写 TLS 端口6380，不是6379） -
sentinel down-after-milliseconds mymaster 5000（TLS 握手稍慢，建议放宽超时） -
sentinel failover-timeout mymaster 180000（避免因证书校验失败导致误判） - 不需要配
tls-*参数——哨兵不参与加密，只读取主从的INFO replication输出中的master_host/master_port，而 Redis 7.0 在启用了tls-port后，INFO replication会自动报告 TLS 端口
如果哨兵连不上主节点，先检查 redis-cli -p 6380 --tls --cert ... --key ... PING 是否通，再确认哨兵配置里写的端口是否与主节点的 tls-port 一致。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
ioredis / node-redis 客户端连哨兵后，如何确保最终走 TLS？
客户端通过哨兵获取主节点地址，但哨兵返回的是它自己看到的 master_host:master_port。如果主节点 redis.conf 正确设置了 tls-port 且 tls-replication yes，哨兵在 SENTINEL get-master-addr-by-name 中返回的就是 6380，而非 6379。此时客户端必须主动启用 TLS：
- ioredis 示例：
const client = new Redis({ sentinels: [{ host: 'sentinel1', port: 26379 }], name: 'mymaster', tls: { ca: readFileSync('ca.crt') } }); - node-redis 示例：
createClient({ sentinel: { hosts: [{ host: 'sentinel1', port: 26379 }] }, name: 'mymaster', socket: { tls: { ca: readFileSync('ca.crt') } } }); - 关键点：客户端的
tls配置必须存在，且证书路径正确；否则即使哨兵返回了6380，客户端也会因缺少tls选项而尝试明文连接，直接报错ERR unknown command `AUTH`（因为 TLS 端口拒绝明文命令）
验证方式：连上后执行 CLIENT INFO，返回中含 tls:1 才算真正走 TLS；若返回 tls:0，说明客户端没配 tls 或证书加载失败。
CA 证书和主机名验证容易被忽略
Redis 7.0 默认不做证书域名校验（即不验证 subjectAltName），但客户端库（如 ioredis）默认会校验。常见坑：
- 生成证书时没加
-addext "subjectAltName = DNS:redis-node1,DNS:redis-node2"，导致客户端连接失败 - ioredis 默认开启
checkServerIdentity，若服务端证书 CN 或 SAN 不匹配实际 IP/DNS，会抛Error: unable to verify the first certificate - 临时绕过方案（仅测试）：
tls: { ca: ..., rejectUnauthorized: false }；生产环境必须用匹配的 SAN 证书 - 哨兵节点虽不加密，但它的
sentinel announce-ip和sentinel announce-port若配成公网地址，客户端拿到后可能连错——务必确保哨兵返回的主节点地址是客户端能路由到的内网 DNS 或 IP
最易漏的一环：主从节点重启后，哨兵需要几十秒重新收集 INFO 并更新主节点端口信息；期间客户端可能拿到旧的 6379 地址，连上去立刻失败。观察 SENTINEL masters 输出里的 ip 和 port 字段是否已更新为 6380 再上线客户端。
