主从复制失败时错误几乎都记录在从节点日志中，因同步请求由从节点发起；需配置logfile和loglevel才能捕获关键错误，如No route to host、NOAUTH Authentication required等，并优先检查网络连通性与masterauth配置。
直接看从节点的 redis.log 文件
主从复制失败时，错误几乎都记录在从节点（replica）的日志里，而不是主节点。因为同步请求由从节点发起，连接、认证、数据接收等环节出错，都会在从节点侧抛出并写入日志。主节点日志通常只显示“有客户端连上来又断了”，不体现具体失败原因。
先确认日志路径：redis-cli CONFIG GET logfile，如果返回空字符串或 ""，说明日志未启用——必须手动配置才能看到有效报错。
- 编辑
redis.conf，取消注释并设置：logfile /var/log/redis/redis-server.log -
loglevel notice足够捕获关键错误；调试阶段可临时设为verbose - 改完后重启 Redis：
systemctl restart redis或kill -SIGUSR1 $(pidof redis-server)（仅重载日志，不中断服务）
tail -f 实时盯住连接建立过程
启动从节点后，立刻用 tail -f /var/log/redis/redis-server.log 观察日志滚动。真正有用的错误往往出现在几秒内，比如：
-
Error condition on socket for SYNC: No route to host→ 主机网络不可达（防火墙/路由问题） -
Error condition on socket for SYNC: Connection refused→ 主节点没监听外网（bind 127.0.0.1没注释） -
MASTER aborted replication with an error: NOAUTH Authentication required→ 从节点缺masterauth配置 -
Connecting to MASTER 192.168.0.103:6379后无后续 → 主节点根本没响应，先检查telnet 192.168.0.103 6379
别只信 info replication 的表面状态
redis-cli info replication 显示 role:slave 和 master_host 不等于复制成功。常见假象：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
master_link_status:down却没报错日志？→ 日志级别太低，或logfile指向了错误路径 -
master_last_io_seconds_ago:120→ 主从心跳中断超 2 分钟，但日志里可能只有模糊的 “I/O error” -
connected_slaves:0在主节点上 → 说明从节点压根没连上来，优先查从节点日志和网络连通性
注意：从节点日志里出现 * MASTER SLAVE sync started 是好信号；如果这行之后没下文，大概率卡在 socket 连接或认证环节。
防火墙和 protected-mode 是高频静默杀手
很多报错看起来像网络问题，实际是 Redis 自身安全机制拦截：
- 主节点开了
protected-mode yes（默认值），且没配bind或requirepass→ 拒绝所有非本地连接，日志里可能只写Client closed connection，不提原因 - 主机防火墙放行了
6379端口，但从节点 IP 不在白名单里（如firewall-cmd --permanent --add-source=192.168.0.50/32漏配） - Docker 或 Kubernetes 环境中，宿主机防火墙 + 容器网络策略 + Service ClusterIP 三重过滤，
telnet成功不代表 Redis TCP 层真通
最简验证法：在从节点机器上执行 redis-cli -h <master-ip> -p 6379 ping</master-ip>，能回 PONG 才算基础通路成立。不通就别调配置，先解决网络和保护模式。
