🚨 Redis Error Guide: 'DENIED Redis is running in protected mode' — Fix Remote Connection Refused

Overview

Redis returns this error to a client that connects from a non-loopback address when protected mode is active and no authentication is configured:

DENIED Redis is running in protected mode because protected mode is enabled and no password is set for the default user. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.

Protected mode is a safety guard added to stop the epidemic of open, passwordless Redis instances being wiped or hijacked on the public internet. When Redis is bound to all interfaces and has no requirepass/ACL password set, protected mode refuses every connection that does not come from 127.0.0.1/::1. It is doing its job: an unauthenticated Redis reachable from other hosts is a critical security hole.

Symptoms

• Remote clients fail immediately with DENIED Redis is running in protected mode.
• redis-cli -h 127.0.0.1 from the same host works, but redis-cli -h <server-ip> from another host is refused.
• Application logs show connection failures right after a new deploy or a bind change.
• Only appears when no password is set — adding auth makes the message go away.

Common Root Causes

• No authentication configured — requirepass is empty and no ACL user has a password, so protected mode engages.
• Client connecting from a non-loopback address — app on another host or container reaching Redis over the network.
• bind left at defaults / bind * with no auth — Redis listens broadly but has nothing to authenticate callers.
• Container/pod networking — the client’s source IP is not loopback from Redis’s perspective, even inside the same node.
• Misunderstanding the fix — disabling protected mode to “make it work” while leaving Redis both internet-reachable and passwordless (the dangerous anti-pattern this guard exists to prevent).

Diagnostic Workflow

Confirm the current protection, bind, and auth posture:

redis-cli CONFIG GET protected-mode
redis-cli CONFIG GET bind
redis-cli CONFIG GET requirepass          # empty string = no password
redis-cli ACL WHOAMI
redis-cli ACL LIST                        # is the default user 'nopass'?

Verify what interfaces Redis is actually listening on:

sudo ss -tlnp | grep redis
redis-cli INFO server | grep -E 'run_id|tcp_port'

Reproduce the boundary — loopback works, remote is denied:

redis-cli -h 127.0.0.1 PING            # PONG
redis-cli -h 10.0.1.20 PING            # (DENIED) protected mode

Check the log for the exact refusal and the client’s source address:

sudo journalctl -u redis-server --since '15 min ago' | grep -iE 'protected mode|DENIED'

Example Root Cause Analysis

After moving Redis to a dedicated node, an application on a separate host began failing every request with DENIED Redis is running in protected mode. redis-cli PING on the Redis box itself returned PONG, so the process was healthy.

CONFIG GET requirepass returned an empty string and ACL LIST showed the default user as nopass. The config had been changed to bind 0.0.0.0 to allow the remote app, but no password was ever set. Protected mode correctly refused the cross-host connections because the instance would otherwise be an open, unauthenticated Redis.

The correct fix was not to disable protected mode. Instead: set a strong password on the default user (or create a dedicated ACL user), restrict bind to the private interface only, and lock the security group / firewall to the app subnet. Once auth was in place, protected mode stood down automatically and the app connected with credentials.

Prevention Best Practices

• Always set authentication: requirepass <strong-secret> or, better, a scoped ACL user with a password. Auth alone makes protected mode stand down.
• Bind to specific private interfaces (bind 10.0.1.20 127.0.0.1), never leave a passwordless instance on 0.0.0.0.
• Put Redis behind a firewall / security group that only allows the application subnet on port 6379.
• Use TLS (--tls-port / port 0) for connections that cross trust boundaries.
• Never run CONFIG SET protected-mode no on an internet-reachable, passwordless instance — that is exactly the exposure this guard prevents.
• Rotate credentials via ACL and keep the default user restricted or disabled in production.

Quick Command Reference

# Correct fix: add authentication (protected mode then stands down)
redis-cli CONFIG SET requirepass 'S0me-Long-Random-Secret'
redis-cli -a 'S0me-Long-Random-Secret' CONFIG REWRITE

# Or a scoped ACL user instead of the shared default
redis-cli ACL SETUSER appuser on '>App-Secret' '~app:*' '+@read' '+@write'

# Restrict the listener to a private interface
redis-cli CONFIG SET bind '10.0.1.20 127.0.0.1'
redis-cli CONFIG REWRITE

# Verify posture
redis-cli -a 'S0me-Long-Random-Secret' CONFIG GET requirepass
sudo ss -tlnp | grep redis

# LAST RESORT (trusted private network only, still add a password after):
# redis-cli CONFIG SET protected-mode no

Conclusion

DENIED Redis is running in protected mode is a security feature, not a malfunction: it blocks remote access to a Redis that has no way to authenticate callers. The right fix is to add authentication and bind to private interfaces behind a firewall — then protected mode stands down on its own. Disabling protected mode without setting a password just recreates the exact open-Redis exposure that has led to countless wiped and ransomed instances.