跨网络主从复制失败的根本原因在于网络层与安全策略未对齐：需显式配置replica-announce-ip、双向密码认证（requirepass+masterauth）、ACL授权+repl权限、放行安全组端口、调优repl-timeout与repl-backlog-size、启用TLS加密，并通过tcpdump验证链路真实性。
跨网络主从复制不是“配完 slaveof 就能通”，混合云环境里最常卡在连接建立不起来、同步中途断开、或数据被中间设备劫持——根本原因不是 Redis 配置错，而是网络层和安全策略没对齐。
主节点必须显式暴露且允许远端握手
云厂商默认安全组/防火墙会拦截非本地 IP 的 REPLCONF 和 PSYNC 请求，仅靠 bind 0.0.0.0 和 protected-mode no 不够。
- 主节点配置中必须设置
replica-announce-ip（Redis 6.2+）或slave-announce-ip（旧版），值为该节点对外可路由的真实公网/私网 IP，不能是内网 NAT 地址或容器网段地址 - 若主节点在 Kubernetes 中，需确认 Service 类型为
NodePort或LoadBalancer，且后端 Pod 端口映射正确；hostNetwork: true更可靠但需评估安全边界 - 云平台安全组要放行从节点所在网段对主节点
6379（或自定义端口）的 TCP 入向连接，同时允许主节点主动向从节点发起出向连接（用于心跳和命令传播）
密码认证必须双向显式配置
主节点设了 requirepass，但从节点连不上，常见原因是漏配 masterauth —— 它和客户端密码无关，专用于从节点向主节点认证。
- 从节点配置中必须写明
masterauth <password></password>，否则主节点日志会报Authentication required，同步直接失败 - 如果主节点启用了 ACL（Redis 6.0+），还需确保用于复制的用户具备
+repl权限，例如：ACL SETUSER repluser on >mypass ~* +repl - 不要依赖
redis-cli -a连接测试来验证主从链路，它只测客户端认证；要用redis-cli -p 6380 info replication查看master_link_status:up才算真正通了
跨公网同步必须处理延迟与断连抖动
混合云间 RTT 通常在 20–100ms，TCP 重传、运营商 QoS、BGP 路由切换都会导致短暂断连，触发全量同步（SYNC），进而打爆带宽和主节点 fork 开销。
- 调大
repl-timeout（默认 60s），建议设为 300，避免因瞬时抖动误判断连 - 增大
repl-backlog-size（默认 1MB），按主节点每秒写入量 × 期望容忍断连时长估算，例如 5MB/s × 300s = 1500MB，至少设为2097152000 - 禁用
tcp-keepalive 0（默认关闭），改为tcp-keepalive 60，让内核主动探测连接活性，早于应用层发现异常 - 避免在跨公网链路上启用
repl-diskless-sync yes，无盘同步依赖稳定的长连接，公网下极易失败回退到低效的磁盘同步
别把加密当成可选，TLS 是混合云的底线
明文同步等于把缓存里的 Token、手机号、订单快照裸奔发到公网。Redis 原生 TLS 支持从 6.0 开始稳定可用，不是实验功能。
- 主从两端都启用
tls-port 6379并关闭port，强制走加密通道；证书需由可信 CA 签发，或使用私有 CA + 从节点配置tls-ca-cert-file - 从节点连接字符串必须用
rediss://协议，例如：redis-cli -u "rediss://repluser:mypass@master.example.com:6379" - 若无法升级 Redis 版本，可用 stunnel 或 socat 做 TLS 代理，但需额外维护进程、证书轮换和故障隔离，复杂度陡增
混合云主从最难的从来不是“怎么配”，而是“怎么让两边网络策略、安全团队、运维流程达成一致”。一个没对齐的 MTU、一条被忽略的 ICMP 丢包日志、一次未通知的 BGP 路由变更，都可能让 master_link_status 在 up 和 down 之间反复横跳。上线前务必用 tcpdump 抓包验证三次握手、PSYNC 流和心跳包是否真实抵达，而不是只信 INFO replication 的输出。
