redis主从复制中slave_repl_offset长时间不动，说明tcp连接正常但数据未同步，核心原因是集群总线端口16379被防火墙/nat/安全组/docker映射或bind配置拦截，导致主从间增量命令无法传输。

从节点显示 connected 但 slave_repl_offset 长时间不动，说明 TCP 连接建成了，数据却没流过去——这几乎一定是网络层“通而不传”，核心要查集群总线端口是否被拦、主从通信路径是否被转发规则破坏。

确认从节点是否真在收增量命令

别只看 cluster nodes 或 INFO replication 里状态是 online 或 up。关键看两个 offset 差值是否变化：

• master_repl_offset 在主节点上持续增长（redis-cli -p 6379 info replication | grep master_repl_offset）
• slave_repl_offset 在从节点上卡住不动（redis-cli -p 6380 info replication | grep slave_repl_offset）
• 差值不变 → 主节点根本没把命令发出去，或从节点压根没收到

检查集群总线端口 16379 是否被防火墙/NAT/转发规则阻断

Redis 主从复制不走客户端端口（6379），而是用「集群总线端口」：主节点端口 + 10000。比如主节点监听 6379，那它对外广播和接收复制数据的端口就是 16379。这个端口一旦不通，就只有连接，没有同步。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 在从节点机器上执行：telnet 16379 或 nc -zv 16379
• 如果失败，立刻检查三处：
  • 主节点本机防火墙：sudo iptables -L INPUT -n | grep 16379（缺规则就加：sudo iptables -I INPUT -p tcp --dport 16379 -j ACCEPT）
  • 云平台安全组：阿里云/AWS/GCP 的入方向规则必须显式放行 16379/tcp，且源地址填对其他节点 IP 段
  • NAT 或端口转发设备：如果主节点在内网，而从节点通过公网 IP 访问，检查路由器/负载均衡器是否只转发了 6379，漏掉了 16379

排查 Docker 或 Kubernetes 环境下的端口映射遗漏

Docker run 或 k8s Pod 配置里，常只暴露 6379，忘了加 -p 16379:16379 或 Service 的 port 定义里没包含总线端口。

• Docker 示例（错误）：docker run -p 6379:6379 redis → 缺 16379 映射
• Docker 正确写法：docker run -p 6379:6379 -p 16379:16379 redis
• K8s Service 中必须有：

  ports:
  - port: 6379
  - port: 16379

• 验证容器内是否监听：docker exec <container> ss -tlnp | grep ':16379'</container>

确认主节点配置未禁用复制通道

即使端口通了，protected-mode yes 且 bind 只写 127.0.0.1 也会让主节点拒绝从节点的复制握手请求，日志里出现 Node not reachable 或反复 REPLICAOF 失败。

• 检查：redis-cli config get protected-mode 必须为 no
• 检查：redis-cli config get bind 不能只有 127.0.0.1，至少得含内网 IP（如 192.168.10.5）
• 改完运行：redis-cli config rewrite 持久化，并重启从节点触发重连

偏移量不动的本质，是主节点的 repl_backlog_buffer 根本没被消费——不是缓冲区太小，而是从节点压根没连上那个“写命令管道”。端口、防火墙、NAT、容器映射、bind 配置，这五环只要断一环，就静默卡死。最容易被忽略的是：你以为在查 6379，其实该盯 16379。