从节点日志报 noauth authentication required，说明主节点启用 requirepass 后，从节点未配置或错配 masterauth，导致认证失败、卡在复制握手阶段，无法进入命令交互。
从节点日志报 NOAUTH Authentication required
这是最常见却最容易被忽略的“假连接”问题：从节点看似在尝试连接，但实际卡在认证环节，根本没走到 TCP 握手后的命令交互阶段。
主节点启用 requirepass 后，从节点作为“客户端”发起 PSYNC 或 INFO 时，必须携带密码；而 requirepass 本身不自动透传给从节点——它只管普通客户端连接。
- 必须在从节点配置中显式设置
masterauth，值与主节点的requirepass完全一致 -
masterauth是从节点专属配置，只用于向主节点认证，和从节点自身是否设密码（requirepass）无关 - 改完后需重启从节点或执行
redis-cli config rewrite+redis-cli replicaof <master-ip><master-port></master-port></master-ip>重触发同步
telnet 6379 成功但 cluster nodes 显示 fail
说明客户端端口通了，但集群总线端口不通——Redis 集群节点间靠 16379（即 6379 + 10000）通信，这个端口专用于心跳、故障检测、槽位迁移等控制消息。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在任一节点上执行
redis-cli -p 6379 cluster nodes，找到失联节点 IP（如192.168.5.20），然后测其总线端口：telnet 192.168.5.20 16379 - Linux 本机检查防火墙：
sudo iptables -L INPUT -n | grep 16379；若无输出，加规则：sudo iptables -I INPUT -p tcp --dport 16379 -j ACCEPT - 云环境（阿里云/AWS）必须在安全组中**单独放行 16379 入方向**，仅开 6379 不够
protected-mode yes 导致集群握手失败
即使端口全通、密码也配对，protected-mode yes 且 bind 没放开内网地址时，Redis 会拒绝来自其他节点的 MEET 请求，日志里反复出现 Node not reachable，但 cluster nodes 可能仍显示 connected——那只是 TCP 连接曾建立过，不代表集群逻辑已就绪。
- 集群模式下必须设为：
protected-mode no（注意：这不是安全漏洞，集群内部通信本就不走密码校验） -
bind不能只写127.0.0.1，至少加上内网 IP，例如：bind 127.0.0.1 192.168.5.10 - 改完运行
redis-cli -p 6379 config rewrite持久化，并用redis-cli -p 6379 cluster forget <old-node-id></old-node-id>清旧状态再重试
从节点连得上但同步延迟持续升高
这通常不是网络问题，而是复制积压缓冲区（repl-backlog-size）太小，导致断线重连时无法做部分重同步，被迫退化为全量复制，进而加剧延迟和带宽压力。
- 检查当前配置：
redis-cli config get repl-backlog-size，默认 1MB，生产环境建议调至 100MB 起 - 增大后需重启或热加载（部分版本支持
config set repl-backlog-size 104857600） - 同时确认
repl-backlog-ttl是否过短，避免缓冲区被提前释放
connecting 的原因，往往不在网络层，而在认证、权限、配置三者的错位组合。一次 NOAUTH 报错背后，可能同时混着 masterauth 缺失、protected-mode 拦截、16379 端口被封三个问题——得逐层验证，不能只盯着 telnet 结果看。
