azure managed redis node connects with ip, not SNI for TLS

Question

azure managed redis node connects with ip, not SNI for TLS

Jon 0

I have an azure managed redis instance set up in OSS Clustering mode. The redis cluster has a hostname xyz.eastus.redis.azure.net, so I can connect to it via TLS and verify that the certificate on the cluster matches the hostname. But when I do 'CLUSTER SHARDS' I get back nodes with IP addresses

    3) "nodes"
   4) 1)  1) "id"
          2) "1"
          3) "tls-port"
          4) (integer) 8501
          5) "ip"
          6) "10.0.0.5"
          7) "endpoint"
          8) "10.10.0.8"
          9) "hostname"

My client library (python redis 8.0.1) then tries to make a TLS connection to one of these IPs (I think 10.10.0.8) but fails because TLS connections cannot be made to pure IPs. The cluster shard should have had a hostname like xyz-shard.eastus.redis.azure.net or something.

I can get this to work by disabling hostname checking in the configuration of my python code like so, but I should not have to do this. Any idea how to get hostnames for shards in azure managed redis?

redis = RedisCluster(host=..., port=10000, password=..., ssl_check_hostnames=False)

Pilladi Padma Sai Manisha 11,605 Reputation points Microsoft External Staff Moderator

2026-07-31T16:46:44.0633333+00:00
Hi @Jon
Thankyou for reaching microsoft Q&A!
Based on your description, the behavior appears to be related to how the Azure Managed Redis service advertises shard endpoints when using the OSS Cluster policy.

Azure Managed Redis with the OSS Cluster policy requires cluster-aware clients to:

Connect to the initial endpoint on port 10000.

Discover shard endpoints using the Redis Cluster protocol (CLUSTER SHARDS/CLUSTER NODES).

Establish subsequent connections to the shard endpoints (typically on ports in the 85xx range).

In your scenario, the cluster is returning IP addresses instead of DNS hostnames for the shard endpoints. Since the TLS certificate is issued for the Redis service hostname rather than the IP address, a client performing hostname verification will fail the TLS handshake when it attempts to connect directly to the advertised IP.

At this time, Microsoft documentation does not describe any supported setting to change the advertised shard endpoints from IP addresses to hostnames, nor does it recommend disabling hostname verification as a permanent solution. The ssl_check_hostnames=False setting is only a workaround and reduces the security provided by TLS.

To help determine whether this is an expected service behavior or a product issue, could you please provide the following information?

Is the Azure Managed Redis instance using Public Access or Private Endpoint/VNet connectivity?

Which Azure Managed Redis tier and Redis version are you using?

Is the hostname field returned by CLUSTER SHARDS empty for every shard?

Does the issue reproduce with another Redis Cluster client (for example, redis-cli --tls)?

If the service consistently advertises only IP addresses for shard endpoints while TLS hostname validation is enabled, this would require further investigation by the Azure Managed Redis engineering team, as there is currently no documented customer configuration to modify this behavior.

For reference:

Azure Managed Redis architecture and clustering

TLS configuration for Azure Managed Redis
Jon 0 Reputation points

2026-07-31T18:29:57.9133333+00:00
Is the Azure Managed Redis instance using Public Access or Private Endpoint/VNet connectivity? Its private only, not through a private endpoint, just through the internal vnet

Which Azure Managed Redis tier and Redis version are you using? Balanced B0, redis 7.4, clustering policy OSS cluster

Is the hostname field returned by CLUSTER SHARDS empty for every shard? Yes, there is only one shard it seems and the hostname is the 10.10.0.8 ip. This is the same ip as the redis endpoint hostname, xyz.eastus.redis.azure.net

Does the issue reproduce with another Redis Cluster client (for example, redis-cli --tls)? No, if I port forward via ssh to the endpoint hostname:10000, redis-cli is able to connect to the cluster through the port forward. I am not sure what it is doing internally to connect to the other shards, or maybe it isn't connecting to the shards at all since there is no ssh port forward enabled for the 85xx ports.
Jon 0 Reputation points

2026-07-31T18:30:28.3866667+00:00

delete

Your answer

Jon 0 Reputation points

2026-07-31T18:29:57.9133333+00:00

Is the Azure Managed Redis instance using Public Access or Private Endpoint/VNet connectivity? Its private only, not through a private endpoint, just through the internal vnet

Which Azure Managed Redis tier and Redis version are you using? Balanced B0, redis 7.4, clustering policy OSS cluster

Is the hostname field returned by CLUSTER SHARDS empty for every shard? Yes, there is only one shard it seems and the hostname is the 10.10.0.8 ip. This is the same ip as the redis endpoint hostname, xyz.eastus.redis.azure.net

Does the issue reproduce with another Redis Cluster client (for example, redis-cli --tls)? No, if I port forward via ssh to the endpoint hostname:10000, redis-cli is able to connect to the cluster through the port forward. I am not sure what it is doing internally to connect to the other shards, or maybe it isn't connecting to the shards at all since there is no ssh port forward enabled for the 85xx ports.
Jon 0 Reputation points

2026-07-31T18:30:28.3866667+00:00

delete