Troubleshooting Private Connectivity to Redis Cloud When DNS Resolves but TCP Fails

AWS PrivateLink and Google Cloud Private Service Connect (PSC) provide private paths from a customer network to Redis Cloud Pro databases. The AWS PrivateLink documentation and GCP Private Service Connect documentation contain the complete setup procedures. This KB is for the specific case where the Redis Cloud hostname resolves successfully, but the client cannot establish a TCP connection to the database port.

A successful DNS lookup confirms only that the hostname can be resolved. It does not confirm that the private endpoint is active, that the application can reach it, or that cloud network controls allow the traffic.

Quick Fix

Prerequisites

• Redis Cloud Pro subscription.

• The exact private hostname and database port from the Redis Cloud Console.

• Access to the customer VPC, project, endpoint, subnet, security controls, and DNS configuration.

• A test host in the same network as the private endpoint, where possible.

• dig or nslookup, nc, and redis-cli. Use a TLS-capable client when TLS is enabled.

For complete setup requirements, use the AWS PrivateLink prerequisites or PSC setup and connection procedure.

Troubleshooting flow

1. Confirm the exact endpoint and port

Use the private endpoint and port generated for the affected database. For AWS, retrieve them from the endpoint Associations tab or the Redis Cloud PrivateLink discovery script. For PSC, retrieve them from the active endpoint in the Redis Cloud Console.

Do not substitute a raw cloud-provider endpoint hostname or a public Redis Cloud endpoint.

2. Test DNS and TCP from two locations

Run the following from the application host or pod and, if possible, from a VM in the endpoint VPC or project:

dig +short <PRIVATE_HOSTNAME>
nc -vz <PRIVATE_HOSTNAME> <DATABASE_PORT>

Interpret the first failing test:

• DNS fails: check private DNS, DNS response policies, VPC DNS settings, forwarding, and stale overrides.

• DNS succeeds and TCP times out: check endpoint state, routes, security groups, firewalls, Network ACLs, and return traffic.

• TCP is refused: verify the endpoint, port, and private connectivity association.

• TCP succeeds but Redis fails: continue with TLS and authentication checks.

3. Check the private connection and cloud network controls

For AWS PrivateLink, verify that:

• The AWS account is an accepted Redis Cloud resource-share principal.

• The resource endpoint is available and uses the Redis Cloud resource configuration ID.

• Private DNS is enabled when the client requires Redis hostname validation.

• The endpoint subnets are in the Redis Cloud database region and have sufficient available IP addresses.

• The selected Availability Zone IDs are supported by AWS VPC Lattice.

• Security groups and Network ACLs allow the database port and return traffic.

For GCP PSC, verify that:

• The PSC connection is accepted and active in the Redis Cloud Console.

• The forwarding rule is active and targets the intended Redis Cloud service attachment.

• The endpoint, application, and DNS response policy are attached to the intended VPC and project.

• Firewall, route, perimeter, and egress controls allow the database port.

Use the provider-specific documentation for configuration changes rather than duplicating those procedures here: AWS PrivateLink and GCP PSC.

4. Separate TCP, TLS, and authentication failures

After TCP succeeds, test Redis directly:

redis-cli -h <PRIVATE_HOSTNAME> -p <DATABASE_PORT> --user <USERNAME> --askpass PING

For TLS-enabled databases:

redis-cli -h <PRIVATE_HOSTNAME> -p <DATABASE_PORT> --tls --user <USERNAME> --askpass PING

Use the Redis Cloud TLS and access-control KB for TLS, hostname, CA, ACL, and allow-list issues. 

Use the Redis Cloud authentication troubleshooting KB for WRONGPASS, AUTH failed, and related errors.

When to contact Redis Support

Contact Redis Support when the connection remains pending, private DNS entries are missing after the documented setup is complete, or the failure persists after an endpoint-local TCP test and cloud-network review.

Include:

• Redis Cloud account, subscription, and database IDs.

• Cloud provider, region, project or AWS account, VPC, subnet, and endpoint ID.

• Private hostname, database port, and resolved IP address.

• Redis Cloud and provider-side connection status.

• Results of dig, nc, and redis-cli, including timestamps and timezone.

• The first failing step: DNS, TCP, TLS, or authentication.

• Relevant route, firewall, security-group, Network ACL, or DNS-policy findings.

Do not delete or recreate an active private endpoint during an incident unless the impact and replacement path are understood. Endpoint changes can interrupt applications using that private path.