redis哨兵无法连接主从实例的根本原因是protected-mode触发：当protected-mode为yes、bind未指定实际ip（如仅127.0.0.1或注释）、且未设置requirepass时，redis会拒绝所有非环回连接，包括同内网的哨兵请求。
Redis 哨兵（redis-sentinel）无法连接主从实例，根本原因不是“哨兵配错了”，而是它被 Redis 实例自身的 protected-mode 拦在了门外——只要主/从/哨兵三者不在同一台机器上，且 Redis 实例满足触发条件，protected-mode 就会拒绝哨兵的 TCP 连接请求，哪怕它们在同一个内网。
为什么哨兵连不上？看清楚 protected-mode 的触发逻辑
protected-mode 不是“开了就全拦”，而是三个条件**必须同时成立**才会生效：
-
protected-mode yes（默认值，即未显式设为no） -
bind配置为空、注释掉、或只写了127.0.0.1（没写实际对外网卡 IP） -
requirepass未设置，或值为空字符串
哨兵集群里，每个哨兵要主动向主节点、从节点发起 PING 和 INFO 请求。一旦某个 Redis 实例（比如主库）满足以上三条，它就会把所有非 127.0.0.1 的连接（包括同网段另一台机器上的 redis-sentinel）直接断开，并在日志里打：Client closed connection due to protected mode。
CONFIG SET protected-mode no 为什么有时不生效
用 redis-cli -h 127.0.0.1 CONFIG SET protected-mode no 确实能临时关闭，但有三个常见坑：
- 只改了当前运行实例，没改配置文件 → 重启后恢复
yes - 哨兵进程自己也读自己的配置（
sentinel.conf），但哨兵**不支持protected-mode配置项**；它连接 Redis 实例时，完全受目标 Redis 实例的protected-mode控制 - 执行
CONFIG REWRITE后，如果redis.conf里bind或requirepass仍不满足安全要求，有些旧版 Redis（如 6.0 之前）可能拒绝写入，导致配置没真正落盘
生产环境该选 bind 还是关 protected-mode
直接设 protected-mode no 是最快解法，但等于放弃一层默认防护。更稳妥的做法是：保留 protected-mode yes，只补上另外两个条件中的至少一个：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 明确绑定监听 IP：
bind 192.168.1.100（填本机真实内网 IP，不要用0.0.0.0） - 强制设置密码：
requirepass my_strong_password，然后在sentinel.conf中补上：sentinel auth-pass mymaster my_strong_password
注意：bind 0.0.0.0 + protected-mode yes 依然会触发保护模式，因为 0.0.0.0 不算“指定了具体 IP”——Redis 认为这是未绑定行为。
哨兵配置里最容易漏掉的一行
即使你关了 protected-mode 或配了 requirepass，如果主库启用了密码，哨兵连上去后发 INFO 会被拒，导致无法获取从库列表、判断主观下线失败。必须在 sentinel.conf 中声明认证信息：
sentinel auth-pass <master-name><password></password></master-name>
其中 <master-name></master-name> 是你在 sentinel monitor 行里定义的名字，不是 Redis 实例的 hostname。漏写这行，哨兵日志里会出现大量 NOAUTH Authentication required，但错误提示里不会明说缺这句。
真正的难点不在“怎么关”，而在关完之后是否意识到：哨兵和 Redis 实例之间是双向信任关系，而 protected-mode 只控制入口，不解决出口权限。任何一步配置错位，都会让整个故障排查陷入“连得上但没反应”的假象。
