v9.18.0: PubSub in TLS-only cluster connects to port 0 instead of TLS port

[ZynovII]

Description

After upgrading from go-redis v9.17.3 to v9.18.0, PubSub connections in a TLS-only Redis cluster (--port 0 --tls-port 6379) attempt to connect to port 0 instead of the correct TLS port 6379. Regular (non-PubSub) operations work correctly.

Error

dial tcp 172.30.0.12:0: connect: connection refused

Logged as: component=pubsub node_address=172.30.0.12:0

Environment

• Redis 7.4.8 cluster, 6 nodes (3 masters + 3 replicas)
• TLS-only mode: --port 0 --tls-port 6379 --tls-cluster yes
• go-redis v9.17.3 → v9.18.0

Key observations

1. CLUSTER SLOTS returns the correct port 6379 for all nodes
2. CLUSTER SHARDS returns tls-port: 6379 but no port field (expected for --port 0 config)
3. Standard Redis operations (PING, SET, GET, etc.) work fine with correct port 6379
4. Only PubSub connections get port 0
5. Reverting to v9.17.3 fixes the issue completely

Analysis

Compared the full diff between v9.17.3 and v9.18.0. The topology discovery via ClusterSlots() correctly returns port 6379. The issue appears to be in how PubSub connections are established in cluster mode.

Relevant changes in v9.18.0 that may contribute:

• newClusterNode → newClusterNodeWithNodeAddress (new nodeAddress parameter)
• New NodeAddress field in Options
• clone() now copies pubSubPool (was missing in v9.17.3)
• New DialTimeout (5s), DialerRetries (5) defaults in ClusterOptions.init()
• New routing system (osscluster_router.go)

Reproduction

This was discovered through LangGraph API which upgraded go-redis from v9.17.3 (in v0.7.56) to v9.18.0 (in v0.7.60). A full reproduction environment is available in the linked LangGraph issue.

Minimal reproduction steps:

1. Set up a 6-node Redis 7.x TLS-only cluster (--port 0 --tls-port 6379)
2. Connect with go-redis v9.18.0 ClusterClient using rediss:// URI
3. Standard operations work
4. PubSub Subscribe fails with dial tcp <node-ip>:0: connection refused

Expected behavior

PubSub should connect to the TLS port (6379), same as regular operations.

Actual behavior

PubSub connects to port 0, which fails immediately.

[ndyakov]

Hello @ZynovII , this is an interesting finding. Thank you for reporting, will get a look at it as soon as possible!

[ndyakov]

Hello @ZynovII I did review the code and did not see any changes between the two versions that may contribute to this being a regression, have you changed your server setup somehow as well? Can you share the output of CLUSTER SLOTS, i do think we can have a workaround for when the port is 0 and use the tls-port if available.

[ilyacadence]

Confirming this bug still exists as of 2026-03-11.
We hit this exact issue after upgrading the LangGraph API Docker image from 0.7.56 (go-redis v9.17.3) to 0.7.69 (go-redis v9.18.0).
https://hub.docker.com/layers/langchain/langgraph-api/0.7.69-py3.12

Environment:

• AWS ElastiCache Valkey 8.1.0, cluster mode enabled, 1 shard / 3 nodes
• Transit encryption: Required (TLS-only)
• Node type: cache.t4g.small
• Configuration endpoint: clustercfg.*.usw2.cache.amazonaws.com:6379

Logs showing port 0:

  redis: 2026/03/11 12:04:40 pool.go:617: redis: connection pool: failed to dial after 1 attempts: dial tcp 172.31.24.227:0: i/o timeout
  time=2026-03-11T12:04:40.321Z level=WARN _msg="Redis ping failed, retrying" component=pubsub node_address=172.31.24.227:0 error="dial tcp 172.31.24.227:0: i/o timeout" attempt=3 backoff_ms=362 _log-at=**/redis/client.go:47


  redis: 2026/03/11 12:04:50 pool.go:617: redis: connection pool: failed to dial after 1 attempts: dial tcp 172.31.24.227:0: i/o timeout
  time=2026-03-11T12:04:50.685Z level=WARN _msg="Redis ping failed, retrying" component=pubsub node_address=172.31.24.227:0 error="dial tcp 172.31.24.227:0: i/o timeout" attempt=4 backoff_ms=745 _log-at=**/redis/client.go:47

PubSub connections attempt to dial port 0 instead of 6379. Standard Redis commands work correctly — only PubSub is affected. Reverting to go-redis v9.17.3 (via langgraph-api 0.7.56) resolves the issue.

[ndyakov]

@ilyacadence can you share the output of cluster slots - https://redis.io/docs/latest/commands/cluster-slots/ . I am not familiar and do not have such env to test with.