通过SSH隧道使用ioredis搭配SSL连接AWS ElastiCache Redis

• 使用非SSLredis://连接串连接卡死的原因：AWS ElastiCache开启传输加密后，服务端要求所有入站连接必须完成TLS握手才能响应Redis协议请求。非SSL客户端不会发送TLS握手包，只会持续等待服务端响应，因此连接状态永久停留在connect阶段，执行命令的Promise永远处于pending状态。
• 使用rediss://连接串报证书校验失败的原因：ioredis默认继承Node.js tls模块的严格校验逻辑，会将连接配置里的主机地址（即本地隧道的127.0.0.1）和Redis服务端证书的备用名称（SAN）做匹配校验。但AWS ElastiCache的服务端证书SAN仅包含官方集群域名（如本例的clustercfg.my-test-redis.amazonaws.com），不存在127.0.0.1的匹配项，因此触发ERR_TLS_CERT_ALTNAME_INVALID报错。

补充说明：你使用的openssl、Python redis客户端能正常连通，是因为这类工具默认不强制校验主机名与证书的匹配关系，和ioredis默认的严格校验逻辑存在差异，因此出现工具间的连通性表现不一致。

注意：仅使用rediss://格式的连接串初始化客户端时，无法传入自定义TLS校验规则，需要通过对象形式的初始化参数传递tls配置块，覆盖默认的严格校验逻辑。

• 方案1（推荐，保留基础证书校验能力）：手动指定TLS校验使用的服务端主机名，让校验逻辑匹配隧道后端真实的Redis域名，而非本地隧道地址。
  初始化ioredis时通过servername参数覆盖TLS校验的主机名匹配规则，示例代码：

  const Redis = require("ioredis");
  const redis = new Redis({
    host: "127.0.0.1",
    port: 6379,
    tls: {
      // 将校验主机名替换为AWS ElastiCache证书中实际包含的集群域名
      servername: "clustercfg.my-test-redis.amazonaws.com"
    }
  });
  

  配置生效后，虽然TCP连接的目标是本地127.0.0.1的隧道端口，但TLS握手时会使用上述域名匹配证书SAN，既可以通过校验，也保留了证书合法性的验证能力，比完全关闭校验更安全。上述配置完全兼容Node.js 12.9、ioredis 4.19.4的运行环境，无需升级依赖版本。

• 方案2（仅适用于本地调试）：直接关闭严格的证书校验逻辑，跳过主机名、证书合法性的全流程校验。
  注意：该配置会完全跳过证书合法性校验，生产环境严禁开启
  配置示例：

  const Redis = require("ioredis");
  const redis = new Redis({
    host: "127.0.0.1",
    port: 6379,
    tls: {
      rejectUnauthorized: false
    }
  });
  

配置完成后，客户端状态会从connect切换为ready，执行set/get等命令可正常返回结果，不会再出现Promise永久pending的问题。

内容的提问来源于stack exchange，提问作者Marvin