redis 6.x tls加密本身不防探测性穿透，真正起作用的是tls-auth-clients配置+客户端证书校验+网络层隔离三者叠加；默认redis-cli --tls仅做服务端单向校验，若未设tls-auth-clients yes并强制客户端证书，则无法阻止未授权访问。

Redis 6.x 的 TLS 加密本身不防“探测性穿透”——它只加密传输内容，不阻止未授权连接尝试。真正起作用的是 tls-auth-clients 配置 + 客户端证书校验 + 网络层隔离三者叠加。单开 TLS 端口但不强制客户端认证，等同于给明文通道套了层透明玻璃。

为什么 redis-cli --tls 连得上不代表安全已生效

默认情况下，redis-cli --tls 只做服务端证书校验（单向 TLS），只要服务端证书格式合法、CA 可信，就允许连接。攻击者只要拿到 CA 根证书（比如从配置文件路径猜出或泄露），就能伪造任意客户端身份连入。

• tls-auth-clients no（默认值）：服务端完全不验客户端证书，仅加密通道，无身份约束
• tls-auth-clients yes：服务端强制要求客户端提供有效证书，且该证书必须由 tls-ca-cert-file 指定的 CA 签发
• 若设为 optional，部分客户端可跳过证书，留下旁路入口

如何让 TLS 真正挡住非授权访问

关键不是“开了 TLS”，而是让服务端拒绝没有合法证书的握手请求。这需要两步硬配置：

Redis Skill - 高性能缓存管理

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

下载

• 在 redis.conf 中显式设置：tls-auth-clients yes（不能依赖默认）
• 确保 tls-ca-cert-file 指向你自建 CA 的根证书（ca.crt），而非服务端证书本身
• 客户端连接时必须带 --cert 和 --key，例如：redis-cli --tls --cert client.crt --key client.key --cacert ca.crt -h x.x.x.x -p 6379
• 私钥文件权限必须是 600，否则 Redis 启动时静默失败或降级为 no 模式

Docker 或 systemd 环境下最容易漏掉的三个点

这些环境会放大配置错误的影响，且错误表现隐蔽：

• 证书路径用相对路径（如 ./certs/redis.crt）：Docker 容器内工作目录不确定，systemd 启动时 WorkingDirectory 不一定匹配，必须用绝对路径
• 私钥带密码但没配 tls-key-file-pass：Redis 启动卡在 stdin 等待输入，日志无报错，表现为“服务未监听任何端口”
• 集群模式下只配了 tls-cluster yes 却漏了 tls-replication yes：主从同步走明文，数据在 replica 节点落地时已裸奔

最常被忽略的是：即使启用了双向 TLS，若防火墙或云安全组仍放行非 TLS 端口（如 6379），攻击者可直接绕过 TLS 层发起未加密连接。TLS 安全通道的前提，是网络层面只暴露 TLS 端口。