redis 6.0集群开启tls后性能下降40%以上，主因是未启用会话复用且缺失aes-ni硬件加速；redis-cli报“ssl handshake failed”多因客户端与服务端tls版本或加密套件不匹配，如旧版客户端仅支持tlsv1.0而服务端默认tlsv1.2+；集群节点通信失败常因证书缺少subjectaltname（san）覆盖cluster-announce-ip地址；qps骤降、cpu满载需立即启用tls-session-caching并确认aes-ni可用；客户端须使用连接池并开启会话复用，或考虑tls卸载至前置代理。
Redis 6.0集群开启TLS后性能下降40%以上，不是配置错了，而是默认没开会话复用+没用AES-NI硬件加速。
redis-cli连接报错“SSL handshake failed”但服务端日志无异常
这通常不是证书问题，而是客户端和服务端TLS版本或加密套件不匹配。Redis 6.0默认启用TLSv1.2+，但旧版redis-cli（如5.x编译的）可能只支持TLSv1.0，握手直接被拒绝。
- 检查客户端TLS能力：
redis-cli --tls -h redis.example.com -p 6379 PING失败时加--insecure临时绕过验证，确认是否纯协议层问题 - 强制服务端降级（不推荐）：
tls-protocols "TLSv1.2"（避免写成TLSv1.0，该版本已废弃） - 真正解法：升级客户端工具链，比如用OpenSSL 1.1.1+编译的
redis-cli，并确保tls-ciphersuites中至少包含TLS_AES_256_GCM_SHA384
集群节点间通信延迟飙升，INFO replication显示master_link_status:down
Redis集群元数据同步、ASK重定向、slot迁移都走redis.conf里cluster-announce-ip声明的地址——如果这个IP没包含在证书的subjectAltName里，节点间TLS握手会静默失败。
- 必须用SAN证书，且
DNS和IP条目要覆盖所有节点宣告地址（包括容器内网IP、宿主机IP、VIP） - 验证方式：
openssl s_client -connect node1:6379 -servername node1.internal -showcerts 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name" - 别依赖
CN字段：OpenSSL 1.1.1+和BoringSSL默认忽略CN，只认SAN
QPS跌到原来的1/3，top看redis-server CPU跑满但load不高
这是典型TLS加密压垮CPU的表现，尤其在短连接场景下。Redis单线程模型无法并行化加解密，所有TLS开销都挤在主线程里。
- 立即生效的缓解项：
tls-session-caching yes+tls-session-cache-size 1000000+tls-session-cache-timeout 300，让客户端复用会话票据，跳过完整握手 - 确认AES-NI是否启用：
grep -q aes /proc/cpuinfo && echo "enabled" || echo "missing"；若缺失，性能损失会从10–20%拉高到40%+ - 禁用低效套件：
tls-ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384"，砍掉RSA密钥交换和CBC模式
客户端频繁新建连接，监控显示TLS handshake time > 200ms
集群环境下，每个redis-cli、每个微服务实例、每个连接池里的空闲连接，只要断开重连就触发完整TLS握手——1–2个RTT叠加非对称加密，必然拖慢。
- 服务端无法控制客户端行为，但可以施加反制：在
redis.conf里设timeout 300（避免连接长期空闲占用资源），同时要求客户端必须用连接池（如lettuce的PoolConfig） - 检查客户端是否启用了会话复用：Java应用需确认
SSLEngine设置了setSessionCacheSize和setSessionTimeout - 终极手段：把TLS卸载到前置代理（如Envoy或nginx），Redis实例退回到明文通信，但仅限内网可信环境
最常被忽略的一点：集群模式下redis.conf里的tls-port和port不能同时监听同一IP，否则节点间gossip消息可能走错协议栈；必须明确指定bind 0.0.0.0配合tls-port 6379和port 0（禁用非TLS端口），或反过来。
