Leave Redis protected-mode on

The fix/etc/redis/redis.conf

protected-mode yes

This is the default. The action here is usually not turning it off.

What it actually does

Protected mode, added in Redis 3.2, is narrower than its name suggests. It applies only when both of these are true:

• Redis is using the default configuration and binding all interfaces, and
• no password is set.

In that specific state, Redis answers queries from loopback and replies to everyone else with an error explaining the problem. It exists because, in Redis’s own words, “many users fail to protect Redis instances from being accessed from external networks” — it is a guard rail for instances nobody configured.

The moment you set a password or an explicit bind, protected mode is no longer what’s protecting you. It stops being relevant rather than becoming stronger.

Why this page is on the list at all

Because of what people do to it.

The symptom is familiar: an application on another host can’t connect, Redis returns the protected-mode error, and the error is searchable. The top answers say to set protected-mode no. That fixes the symptom in seconds.

What it actually does is remove the only thing standing between an all-interfaces, no-password Redis and the internet. The instance was already misconfigured; protected mode was catching it. Turning it off is often step one of the story that ends with the instance being used to write an SSH key.

If protected mode is blocking a legitimate client, protected mode is not the problem. The problem is that the instance has no password and binds every interface. Fix that — bind it and authenticate it — and the error disappears on its own, because protected mode deactivates itself once either condition is met.

This is why it’s medium and not higher: on a correctly configured instance the setting does nothing at all. It only matters on instances that got the important things wrong — which, empirically, is a lot of them.

Verify it worked

Confirm it’s on:

redis-cli CONFIG GET protected-mode

Expect yes.

More useful is to check whether it’s currently doing anything, which tells you whether the real controls are in place:

redis-cli CONFIG GET bind
redis-cli CONFIG GET requirepass
redis-cli ACL LIST

If bind is explicit and authentication is configured, protected mode is inert — that’s the healthy state. If protected mode is the only reason remote clients are being refused, you have a configuration problem it is temporarily hiding.

Before you apply this

No lockout or outage risk from leaving it on — an instance that is correctly bound and authenticated is unaffected.

The risk is entirely in turning it off. If you are about to set protected-mode no because something can’t connect, stop and check what the instance would look like without it:

sudo ss -lntp | grep -E 'redis|valkey'   # bound to 0.0.0.0?
redis-cli ACL LIST                        # default user still on with nopass?

If the answers are “yes” and “yes”, disabling protected mode publishes an unauthenticated Redis to every network the host can reach. Bind and authenticate first; then you won’t need to touch this setting.

Related

• Bind Redis to a private interface — the real fix for the error.
• Require authentication with ACL users — the other half.