Redis "Connection Refused" on Port 6379: Causes and Fixes

Connection refused on port 6379 means your client reached the target machine and the operating system answered that no process is accepting connections on that address and port. It is a fast, definite answer, which makes it easier to diagnose than a timeout. You will see it in several forms:

Could not connect to Redis at 127.0.0.1:6379: Connection refused
Error: connect ECONNREFUSED 127.0.0.1:6379
redis.exceptions.ConnectionError: Error 111 connecting to localhost:6379. Connection refused.

Error 111 is the Linux ECONNREFUSED code. For the generic Node pattern, see Node ECONNREFUSED.

Step 1: is Redis running?

redis-cli ping                       # expect PONG
sudo systemctl status redis-server   # Debian/Ubuntu
sudo systemctl status redis          # RHEL-family, Arch
ps aux | grep [r]edis-server

If it is stopped, start it and read why it stopped: sudo journalctl -u redis-server -n 50 or the file named by logfile in the config (often /var/log/redis/redis-server.log). Redis can fail at startup because of a bad config line, a permission problem on its data directory, or a port already used by another process. Check the last with sudo ss -tlnp | grep 6379.

If Redis starts but then rejects writes, the symptoms differ; see Redis MISCONF can't persist and Redis OOM command not allowed.

Step 2: is it listening on the address you connect to?

sudo ss -tlnp | grep redis
redis-cli -h 127.0.0.1 -p 6379 ping
redis-cli -h 10.0.0.5 -p 6379 ping

Look at the local address column. 127.0.0.1:6379 means loopback only, so connections from other machines will be refused. *:6379 or 0.0.0.0:6379 means all IPv4 interfaces. The relevant settings in redis.conf:

bind 127.0.0.1 -::1
port 6379
protected-mode yes

Defaults and the exact bind line differ across versions and packages, so check your own file. To accept remote clients, bind to the private interface address (for example bind 127.0.0.1 10.0.0.5), not the public one.

Also confirm the port: managed services and some images use a custom port or TLS port, and your REDIS_URL should match.

Step 3: understand protected mode

If Redis is bound to a non-loopback address with no password, protected mode makes it answer remote clients with a DENIED Redis is running in protected mode message rather than serving them. That is a different error from "connection refused", and it exists for a reason: an open Redis server is a frequent target for attackers.

Set a password with requirepass (or ACLs) and see Redis NOAUTH authentication required for the matching client error.

Step 4: check the network path (remote Redis)

When the server is another machine, ask whether the port is reachable at all. A refused result still means the host is up. A timeout means filtering instead (see connection refused vs timed out). Test with:

nc -vz 10.0.0.5 6379

and use the Port Checker for a public address, though you should not need Redis open on a public IP. Verify host firewall rules (sudo ufw status), cloud security groups, and that the hostname resolves to the right IP with the DNS Checker.

Step 5: Docker and Kubernetes networking

A very frequent cause. Inside a container, localhost is the container itself, not your host and not the Redis container.

• Docker Compose: use the service name as the host: redis://redis:6379. Both services need to share a network, and the app may start before Redis is ready, so add a healthcheck and depends_on with condition: service_healthy.
• App in a container, Redis on the host: use the host's address, for example host.docker.internal on Docker Desktop, or the bridge gateway on Linux, and make Redis bind to an interface the container can reach.
• Published ports: -p 6379:6379 is only needed for access from outside Docker; container-to-container traffic uses the internal network.
• Kubernetes: use the Service DNS name (redis.default.svc.cluster.local) and confirm the Service has endpoints with kubectl get endpoints redis.

Step 6: check client configuration

Confirm environment variables are actually loaded (REDIS_URL, REDIS_HOST, REDIS_PORT), that you are not falling back to the default localhost:6379 because a variable was missing, and that your library version supports your URL scheme (rediss:// for TLS).

Verify

redis-cli -h <host> -p 6379 ping returns PONG, your application starts without connection errors, and a short read/write round trip works (redis-cli set test 1 then get test). Add a TCP check on the Redis port with the Uptime Monitor from a private vantage point if you can, or monitor the app endpoint that depends on Redis.

Next steps

• Review Redis NOAUTH authentication required.
• Read Redis MISCONF can't persist.
• Learn the difference in connection refused, timed out and reset.
• Check app availability with the Website Health Check.

FAQ

Why does it work with redis-cli but not from my app?

They may point to different hosts or ports. In containers, localhost inside the app container is not the Redis container. Print the connection settings your app actually uses.

Is port 6379 the only Redis port?

It is the default, and many services use it, but you can change it in redis.conf. TLS setups sometimes use another port.

What does protected mode do?

It stops Redis serving remote clients when it has no password and is not restricted to loopback. It is a safety net, not a substitute for a firewall and authentication.

Can a firewall cause connection refused?

Some firewalls reject with a reset, which looks like refused, but most drop packets and cause timeouts. Check the service first, then the network.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.