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 端口。
