哨兵端口与加密
哨兵自己会监听一个端口用来接收其他哨兵和客户端的命令，默认是 26379，跟数据实例的 6379 完全是两回事。Redis 6.0 起哨兵也支持 TLS，可以把「客户端到哨兵」「哨兵到数据实例」「哨兵之间」这几条链路的流量分别加密，避免拓扑与命令明文暴露。
基本信息
| 默认端口 | 26379，可用 port 参数修改 |
|---|---|
| 协议 | 文本 RESP，与数据实例一致 |
| TLS 支持 | Redis 6.0 起提供相关 tls-* 参数 |
| 部署要求 | 所有哨兵使用一致端口与一致安全策略 |
典型使用场景
- 新增哨兵节点后核对端口与连通性
- 加固内网拓扑信息，避免哨兵命令被明文抓取
- 跨机房部署时为跨境链路启用加密
- 变更端口后同步更新客户端、防火墙与监控采集目标
- 投票失败时确认哨兵互相访问的端口是否放行
端口核对
端口核对
# 哨兵自身存活与端口监听情况
redis-cli -p 26379 PING
ss -lntp | grep 26379
# 看监控的主库与各哨兵地址，端口配错时这里最容易暴露
redis-cli -p 26379 SENTINEL MASTERS
redis-cli -p 26379 SENTINEL SENTINELS mymaster
# 客户端取主库地址时连的也是哨兵端口，不是 6379
redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster常见端口分工
| 端口 | 用途 | 注意点 |
|---|---|---|
| 6379 | 数据实例默认端口 | 业务读写走这里 |
| 26379 | 哨兵默认端口 | 管理与仲裁走这里 |
| 6380 / 26380 | 常见的第二实例与第二哨兵约定 | 部署前确认无冲突 |
| tls-port | 启用加密后的监听端口 | 可能与明文端口并存 |
| monitor 里的端口 | 被监控实例的真实端口 | 写错会导致哨兵误判主库下线 |
启用加密时通常会有明文与加密两套监听并存的能力，无论取舍如何，哨兵之间与哨兵到实例这两条链路的策略要保持一致，否则一方握手失败，仲裁结果就会失真。
改端口后忘记放行防火墙，会出现「哨兵进程在跑、客户端却连不上」这种看起来矛盾的现象；端口变更需要同步改动客户端、监控与网络策略，建议按变更单执行。