主节点配置 requirepass 后从节点同步失败，因从节点未配置 masterauth 导致认证失败；需在从节点配置文件中设置 masterauth 或运行时 CONFIG SET，并配合 ACL 权限、bind 限制与防火墙加固。
主节点配置 requirepass 后从节点同步失败
Redis 主从复制本身不校验密码，requirepass 只作用于客户端连接认证，从节点作为“客户端”发起 SYNC/PSYNC 时若未提供密码，主节点会拒绝其命令请求（如 INFO、PSYNC），表现为从节点日志持续报错：NOAUTH Authentication required，状态卡在 connecting 或反复重连。
- 主节点启用
requirepass后，必须在从节点配置masterauth，否则复制链路无法建立 -
masterauth是从节点专用配置，只用于向主节点认证，不影响从节点自身是否需要密码 - 若主节点使用 ACL（Redis 6.0+），需确保复制用户具备
+replconf、+psync、+ping权限，仅+all不够安全
从节点如何正确设置 masterauth
masterauth 必须写在从节点的配置文件（如 redis.conf）中，或通过 CONFIG SET masterauth "xxx" 运行时生效（但重启后丢失）。它不是客户端 AUTH 命令，不能靠 redis-cli 登录后执行。
- 静态配置最稳妥：在从节点
redis.conf中添加masterauth your_password，然后redis-cli shutdown再重启服务 - 运行时设置仅作临时调试：
redis-cli CONFIG SET masterauth "xxx"，随后执行redis-cli REPLICAOF <master_ip><master_port></master_port></master_ip> - 若主节点启用了 ACL，
masterauth应填用户名+密码格式：masterauth "replicator:password123"（需配合requirepass或 ACL 用户创建）
ACL 用户替代 requirepass 的安全实践
单纯用 requirepass 是全局密码，所有客户端（包括潜在攻击者）只要知道密码就能执行任意命令。ACL 方式可为复制行为分配最小权限用户，更可控。
- 在主节点创建专用复制用户：
redis-cli ACL SETUSER replicator on >p@ssw0rd ~* +replconf +psync +ping -@all - 从节点配置改为：
masterauth "replicator:p@ssw0rd" - 禁用默认用户密码：
redis-cli ACL SETUSER default off nopass -@all，彻底关闭无密码访问 - 注意：ACL 配置需持久化，执行
redis-cli ACL SAVE写入aclfile，否则重启丢失
防火墙与 bind 配合 requirepass 才算真正加固
仅靠 requirepass 或 masterauth 不能防止未授权节点发起复制请求——攻击者只要能连上主节点端口，就可尝试暴力破解密码或利用弱密码获取 RDB 数据。
- 主节点必须限制监听地址：
bind 10.0.1.100（仅内网 IP），禁用bind 0.0.0.0或注释掉 bind 行 - 操作系统级防火墙放行仅从节点 IP：
iptables -A INPUT -s 10.0.1.101 -p tcp --dport 6379 -j ACCEPT - Redis 6.2+ 支持
replica-announce-ip和replica-announce-port，避免从节点 NAT 后上报错误地址导致主节点反向连接失败
密码只是身份验证一环，网络层隔离没做，再强的 requirepass 也挡不住端口暴露在公网的实例。
