必须显式配置tls-replication yes，否则主从复制默认走明文；主从均需启用该参数，且从节点replicaof须指向主节点tls-port，证书链、SAN及CA验证必须一致。
Redis 6.0 起原生支持 TLS，主从复制链路必须显式启用 tls-replication yes，否则即使服务端配置了 TLS 端口，复制流量仍走明文——这是最常被忽略的致命配置项。
主从双方都必须开启 tls-replication
Redis 主从复制默认不走 TLS，哪怕你已配置 tls-port 和证书，replicaof 指令仍会尝试连接非 TLS 端口（或 fallback 到明文端口），导致复制失败或降级为未加密通信。
-
tls-replication yes必须同时出现在主节点和从节点的redis.conf中 - 主节点需监听 TLS 端口（如
tls-port 6379），并禁用明文端口（port 0） - 从节点的
replicaof必须指向主节点的tls-port，例如：replicaof 10.0.1.100 6379 - 若主节点同时开放明文端口（
port 6379+tls-port 6380），从节点可能意外连上明文端口，造成加密失效
证书路径与 CA 验证必须一致
从节点在建立 TLS 复制连接时，会验证主节点证书。若使用自签名证书或私有 CA，必须确保从节点能信任该证书链，否则复制握手直接失败，日志中出现 SSL_connect failed 或 certificate verify failed。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点只需配置
tls-cert-file和tls-key-file（服务端身份） - 从节点必须额外配置
tls-ca-cert-file，指向主节点证书的签发 CA（如/etc/redis/certs/ca.crt） - 若主节点证书含 SAN（Subject Alternative Name），且 DNS/IP 不匹配
replicaof中的地址，TLS 握手会因域名验证失败而中断 - 建议在生成主节点证书时，明确添加 IP 或域名 SAN，避免仅依赖 CN
常见错误现象与定位方式
复制无法建立、日志反复重试、INFO replication 显示 master_link_status:down，但网络可达——大概率是 TLS 层面问题。
- 检查主节点日志：搜索
Failed to accept client或SSL handshake failed，确认是否因客户端（即从节点）证书不被接受 - 检查从节点日志：出现
Unable to connect to MASTER后跟ssl=1，说明已尝试 TLS 连接；若紧接error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed，即 CA 验证失败 - 手动测试 TLS 连通性：
openssl s_client -connect master-ip:6379 -CAfile /path/to/ca.crt，观察 VERIFY RETURN CODE 是否为 0 - 注意：
redis-cli --tls默认不校验服务器证书，而复制连接强制校验，二者行为不等价
性能与协议版本的实际影响
TLS 握手和加解密开销真实存在，尤其在高吞吐复制场景下，TLSv1.3 相比 TLSv1.2 可降低约 30% 的首次握手延迟，但需主从 OpenSSL 版本均 ≥ 1.1.1。
- 务必设置
tls-protocols "TLSv1.2 TLSv1.3"，禁用 TLSv1.1 及以下（Redis 6.0+ 默认仅启 TLSv1.2） -
tls-ciphersuites仅对 TLSv1.3 生效，如需启用 ChaCha20 加密套件，必须配tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256 - 开启
tls-session-caching yes可显著减少重复握手开销，尤其在主从频繁断连重连时 - 不要忽略
tls-auth-clients no（默认值）：主从复制不要求客户端证书认证，设为yes会导致从节点因无证书而被拒绝
主从 TLS 最容易卡在「以为配好了证书就自动加密」这一步——tls-replication 是开关，不是可选项；CA 信任链是前提，不是可省略项；日志里的 SSL 错误码比连接超时更值得优先排查。
