The "ERR Failed to resolve hostname" error occurs when Redis or a Redis client cannot resolve a hostname to its IP address through DNS. This is typically caused by DNS configuration issues, network connectivity problems, or incorrect hostname configuration.
When Redis tries to connect to a host specified by name (rather than IP address), it uses DNS to resolve that hostname to an IP address. If DNS lookup fails—whether due to misconfiguration, network issues, or an invalid hostname—Redis will return this error. This commonly occurs in Redis Sentinel deployments, cluster setups, or when connecting through intermediate services. In some cases, particularly with Redis versions below 6.2 in Sentinel mode, hostname resolution may not be enabled by default, requiring explicit configuration to function.
First, confirm that the hostname you're trying to connect to is correct and can be resolved. Test DNS resolution using standard tools:
# Using nslookup
nslookup redis-server.example.com
# Using dig for more detailed information
dig redis-server.example.com
# Using ping to test connectivity
ping redis-server.example.comIf these commands fail to resolve the hostname, the issue is a DNS problem, not Redis. Check that the hostname exists and is registered in DNS.
If hostname resolution failed, try connecting using the IP address instead. First, get the IP address:
nslookup redis-server.example.com
# Look for the "Address:" field in the outputThen test Redis connection with the IP:
redis-cli -h 192.0.2.1 -p 6379 pingIf this works, the Redis server is fine—the problem is DNS resolution. If this also fails, the server itself may be unreachable.
Verify that your system's DNS configuration is correct:
# Check DNS servers
cat /etc/resolv.confLook for nameserver entries. Common valid configurations include:
- nameserver 8.8.8.8 (Google DNS)
- nameserver 1.1.1.1 (Cloudflare DNS)
- Internal DNS servers in your network
If the file is empty or missing, add valid nameservers:
# Edit the file (requires sudo)
sudo nano /etc/resolv.conf
# Add nameservers if missing
nameserver 8.8.8.8
nameserver 8.8.4.4If running Redis in Docker, ensure proper networking:
Using docker-compose:
version: '3'
services:
redis:
image: redis:latest
networks:
- backend
app:
image: myapp:latest
networks:
- backend
environment:
REDIS_HOST: redis # Use service name, not localhost
networks:
backend:Verify containers are on the same network:
docker network ls
docker network inspect <network-name>Connect using the service name (e.g., redis), not localhost or 127.0.0.1.
In Kubernetes, ensure DNS resolution is working within the cluster:
Check if CoreDNS is running:
kubectl get pods -n kube-system | grep corednsTest DNS resolution from a pod:
kubectl run -it --rm debug --image=busybox -- sh
# Inside the pod, test:
nslookup redis-service.default.svc.cluster.localFor Redis Sentinel in Kubernetes, use fully qualified domain names:
redis-master-0.redis.default.svc.cluster.local
redis-master-1.redis.default.svc.cluster.localIf using Redis Sentinel 6.2 or later, explicitly enable hostname resolution in your sentinel.conf:
# Edit sentinel.conf
sudo nano /etc/redis/sentinel.conf
# Add these lines:
sentinel resolve-hostnames yes
sentinel announce-hostnames yesThen restart Sentinel:
sudo systemctl restart redis-sentinelFor earlier Redis versions (< 6.2), you must use IP addresses instead of hostnames in configuration.
Ensure that DNS queries (port 53) and Redis connections (port 6379) are not blocked:
# Test DNS port
nc -zv 8.8.8.8 53
# Test Redis port
nc -zv redis-server.example.com 6379
# Check firewall rules (on Linux with ufw)
sudo ufw statusIf blocked, add firewall rules:
# Allow outbound DNS
sudo ufw allow out 53/udp
# Allow Redis connections
sudo ufw allow 6379/tcpRedis Sentinel has specific hostname resolution behavior. In versions prior to 6.2, Sentinel always stored and announced master/slave connection information as IP addresses, making failover problematic in environments with dynamic IPs (like Kubernetes). Redis 6.2+ introduced the sentinel resolve-hostnames and sentinel announce-hostnames directives to address this.
In Kubernetes StatefulSets, the issue is particularly acute because IP addresses change on pod restarts, but service DNS names remain stable. Setting slave-announce-ip to the Kubernetes service name (e.g., redis-service.default.svc.cluster.local) is critical for proper failover behavior.
For cloud-hosted Redis (AWS ElastiCache, Azure Cache, DigitalOcean, etc.), the endpoint is already a resolvable hostname managed by the provider—ensure your security groups/network rules allow outbound DNS and port 6379 connections.
If using TLS/SSL connections to Redis, also verify that the hostname in the certificate matches the hostname you're connecting to, as certificate validation will fail on hostname mismatch.
ERR fsync error
How to fix "ERR fsync error" in Redis
CLUSTERDOWN The cluster is down
How to fix 'CLUSTERDOWN The cluster is down' in Redis
ERR Job for redis-server.service failed because a timeout was exceeded
Job for redis-server.service failed because a timeout was exceeded
ERR Unbalanced XREAD list of streams
How to fix "ERR Unbalanced XREAD list" in Redis
ERR syntax error
How to fix "ERR syntax error" in Redis