🚨 Redis Error Guide: 'Could not connect to Redis ... Connection refused' — Nothing Is Listening on the Port

Overview

Connection refused means the TCP handshake reached the target host and port but nothing accepted it. For Redis this almost always means one of three things: the redis-server process is not running, it is listening on a different address/port than you connected to, or a firewall is rejecting (not silently dropping) the packet.

The literal error you will see from redis-cli or a client library:

Could not connect to Redis at 127.0.0.1:6379: Connection refused

redis.exceptions.ConnectionError: Error 111 connecting to 10.0.0.20:6379. Connection refused.

The key distinction: Connection refused (the port actively rejected you — usually nothing listening) versus Connection timed out (packets were dropped — usually a firewall). Getting that distinction right cuts the diagnosis in half.

Symptoms

• redis-cli PING fails immediately with Connection refused.
• Application startup fails with connection errors to the Redis host.
• The error is instant (refused), not after a delay (timeout).

redis-cli -h 127.0.0.1 -p 6379 PING

Could not connect to Redis at 127.0.0.1:6379: Connection refused

redis-cli -h 10.0.0.20 -p 6379 PING

Could not connect to Redis at 10.0.0.20:6379: Connection refused

Common Root Causes

1. redis-server is not running

The service is stopped, crashed, or was never started.

sudo systemctl status redis-server --no-pager
ss -ltnp | grep 6379

● redis-server.service - Advanced key-value store
     Active: failed (Result: exit-code) since Fri 2026-07-03 01:59:12 UTC

An empty ss result for 6379 confirms nothing is listening.

2. Redis is bound to a different interface

bind 127.0.0.1 means Redis only accepts local connections; remote clients get refused.

redis-cli CONFIG GET bind      # if you can reach it locally
grep -E '^bind|^port' /etc/redis/redis.conf
ss -ltnp | grep redis

bind 127.0.0.1 -::1

LISTEN 0 511 127.0.0.1:6379 ...

Listening on 127.0.0.1 only refuses any connection to the host’s LAN IP.

3. Wrong host or port

The client points at the wrong port (e.g. 6380, a TLS port 6379 vs plain), or the wrong host entirely.

grep -E '^port|^tls-port' /etc/redis/redis.conf
redis-cli -h <HOST> -p <PORT> PING

4. protected-mode with no auth

With protected-mode yes (default) and no password/bind, Redis refuses non-loopback connections by design.

grep -E '^protected-mode|^requirepass|^bind' /etc/redis/redis.conf

5. Firewall rejecting the port

A firewall configured to REJECT (rather than DROP) produces an immediate refused.

sudo iptables -L -n | grep 6379
sudo ufw status | grep 6379

Diagnostic Workflow

Step 1: Is the process alive and listening?

sudo systemctl status redis-server --no-pager
ss -ltnp | grep -E ':6379|:6380'
ps -ef | grep [r]edis-server

No listener → start/fix the service. A listener on 127.0.0.1 only → binding issue.

Step 2: Test locally on the box first

redis-cli -h 127.0.0.1 -p 6379 PING

If local works but remote is refused, it is a bind/protected-mode/firewall issue, not a dead server.

Step 3: Read the log to see why it is down or refusing

sudo journalctl -u redis-server --no-pager | tail -30
sudo tail -50 /var/log/redis/redis-server.log

# Warning: Could not create server TCP listening socket 0.0.0.0:6379: bind: Address already in use

Step 4: Check bind/port/protected-mode config

grep -E '^bind|^port|^protected-mode|^requirepass|^tls-port' /etc/redis/redis.conf

Step 5: Test the network path from the client host

nc -vz <REDIS_HOST> 6379
redis-cli -h <REDIS_HOST> -p 6379 PING
sudo iptables -L -n | grep 6379

refused from nc → nothing listening on that IP; timed out → firewall dropping.

Example Root Cause Analysis

At 02:00 the web tier can no longer reach Redis: every request logs Error 111 connecting to 10.0.0.20:6379. Connection refused. The error is instant, pointing at “nothing listening” rather than a firewall drop.

SSHing to the Redis host, redis-cli -h 127.0.0.1 PING also fails — so the server itself is down, not a bind problem. systemctl status shows failed, and the log gives the reason:

# Fatal error loading the DB: Bad file format reading the append only file: make a backup ...
# Redis is now ready to exit, bye bye...

A truncated AOF from an unclean shutdown crashed startup. The fix is to repair the AOF and restart:

redis-check-aof --fix /var/lib/redis/appendonlydir/appendonly.aof.1.incr.aof
sudo systemctl start redis-server
ss -ltnp | grep 6379          # now listening
redis-cli PING                # -> PONG

Once the server is back and listening on the correct address, the web tier reconnects. Longer term, appendfsync everysec plus clean shutdowns and monitored disk prevent the AOF corruption that started it.

Prevention Best Practices

• Monitor the port with a redis-cli PING health check and alert on the service being down.
• Set bind to the intended interfaces explicitly and confirm with ss -ltnp; use protected-mode yes plus requirepass/ACLs rather than opening 0.0.0.0 unprotected.
• Keep port/tls-port consistent between server config and every client’s connection string.
• Enable systemctl enable redis-server and a restart policy so a crash self-recovers.
• Firewall Redis to only the app subnet; prefer DROP semantics but know REJECT shows as “refused”.
• Never expose Redis to the public internet without auth and TLS.
• Paste the client error and log tail into the free incident assistant, and see more Redis guides.

Quick Command Reference

# Is it running and listening?
sudo systemctl status redis-server --no-pager
ss -ltnp | grep -E ':6379|:6380'
ps -ef | grep [r]edis-server

# Test local vs remote
redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h <HOST> -p <PORT> PING
nc -vz <HOST> 6379

# Why is it down / refusing?
sudo journalctl -u redis-server | tail -30
grep -E '^bind|^port|^protected-mode|^requirepass' /etc/redis/redis.conf

# Firewall
sudo iptables -L -n | grep 6379

Conclusion

Could not connect to Redis ... Connection refused means the port actively rejected the connection — the packet arrived but nothing accepted it. The typical root causes are:

1. redis-server is stopped or crashed (nothing listening).
2. Redis is bound to 127.0.0.1 only, refusing remote clients.
3. The client is using the wrong host or port.
4. protected-mode refusing an unauthenticated remote connection.
5. A firewall REJECTing the port.

Always test locally on the Redis host first: if 127.0.0.1:6379 also refuses, the server is down — read the log. If local works but remote is refused, it is a bind, protected-mode, or firewall issue. And remember refused (nothing listening) versus timed out (firewall dropping) tells you which path to chase.