Redis哨兵无法自动切主的本质是网络连通性断裂，需同时放行哨兵端口（如26379）、主节点Redis端口（如6379）及从节点Redis端口（如6380），三者缺一不可；任一telnet不通即可锁定防火墙拦截。
Redis哨兵无法自动切主，若根源在内部通信端口被防火墙拦截，问题本质不是配置逻辑错误，而是网络连通性断裂——哨兵之间、哨兵与主从节点之间的心跳、投票、重配置指令全部中断，整个故障转移流程会在第一步就卡死。
必须放行的三类端口
哨兵集群依赖三组独立但缺一不可的网络通路，仅开放哨兵监听端口（如26379）远远不够：
- 所有哨兵自身的监听端口：比如26379、26380、26381，需确保彼此能 telnet 通（双向）
- 主节点 Redis 端口：如6379，哨兵要持续 PING 主库、获取 INFO、执行 SENTINEL is-master-down-by-addr
- 所有从节点 Redis 端口：如6380、6381，哨兵选举后需向从节点发送 REPLICAOF 指令，还需检查其复制状态
快速验证是否为防火墙问题
不依赖日志猜测，直接用最小路径确认：
- 在任一哨兵机器上，执行：telnet （如 telnet 192.168.5.10 26380）
- 同样执行：telnet 6379 和 telnet 6380
- 只要任一连接失败，且确认服务进程正常运行，基本可锁定为防火墙或安全组拦截
不同环境下的放开操作
根据部署方式精准处理，避免“全开端口”的粗放做法：
- Linux 物理机/虚拟机：用 firewall-cmd --add-port=26379/tcp --permanent 逐个添加，再 reload；或用 iptables -I INPUT -p tcp --dport 6379 -j ACCEPT
- Docker 部署：必须在 docker run 时用 --publish 显式暴露哨兵端口和 Redis 端口（EXPOSE 不生效）；容器内访问宿主机地址时，注意使用 host.docker.internal 或实际宿主 IP，而非 127.0.0.1
- 云厂商（阿里云/腾讯云等）：检查安全组规则——不仅要看入方向是否允许目标端口，还要确认源 IP 是其他哨兵/主从节点的真实内网 IP，不能只写 0.0.0.0/0
验证通路恢复后的关键动作
端口放开后，不要立即重启全部哨兵，先做两件事：
- 在哨兵上执行 SENTINEL SENTINELS
，确认返回的哨兵列表完整（数量匹配、ip/port 正确） - 执行 SENTINEL MASTER
，观察 num-other-sentinels 是否上升，flags 中是否出现 +sdown 或 +odown 的变化痕迹 - 若仍无反应，检查哨兵日志中是否还有 “Connection refused” 或 “timeout” 字样——有则说明某条通路仍未打通
