Configure Redis Remote Access with bind and protected-mode

Redis remote access comes down to two directives in redis.conf: bind and protected-mode. Out of the box Redis listens only on the loopback address, so a client on another machine gets Connection refused or DENIED Redis is running in protected mode until you change both the listener and the firewall.

This guide walks through editing redis.conf on a Linux VPS, restarting the service, opening port 6379 to one client IP, and confirming the connection from the remote side.

Before you start

You need:

• A Linux VPS with Redis installed and running. If it is not installed yet, start with how to install and secure Redis on a Linux VPS.
• Root or a sudo-capable account.
• The IP address your client connects from, for example 203.0.113.10.
• A strong password ready to paste into requirepass.

Two things to understand before you open anything:

• Redis has no user accounts by default. Authentication is either a single requirepass password or ACL users added later. Without one of those, anyone who reaches port 6379 can read and write every key.
• Traffic is not encrypted unless you configure TLS. If the client is on the public internet, either set up TLS or tunnel Redis over SSH or a private network.

How Redis decides whether to accept a remote connection

Three settings interact:

• bind — the addresses Redis listens on. The default is loopback only (127.0.0.1 -::1).
• protected-mode — a safety net. When it is on and no bind address is set and no password is set, Redis accepts loopback connections only and rejects everything else with a DENIED error.
• requirepass — the password clients must send with AUTH.

The practical consequence: once you set an explicit bind address, protected mode no longer blocks remote clients. You can leave protected-mode yes and still serve remote traffic, which is the safer configuration.

Step 1: Back up redis.conf

Find the config file and the service name first. Debian and Ubuntu use /etc/redis/redis.conf with the unit redis-server. RHEL-family systems also use /etc/redis/redis.conf, but the unit may be redis, redis6 or redis7 depending on the module stream.

systemctl list-units --type=service | grep -i redis
redis-server --version
sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.bak.$(date +%F)

If your file lives elsewhere, check the vendor documentation for your distribution — paths change between packages.

Step 2: Set the bind address

Open the file and find the bind line.

sudo nano /etc/redis/redis.conf

Replace the loopback-only line with the server's own address plus loopback:

bind 127.0.0.1 203.0.113.10

Use the private or public IP that clients will actually reach. Binding to a specific address is better than 0.0.0.0 because Redis then ignores traffic arriving on interfaces you did not intend to expose.

If you genuinely need every interface, bind 0.0.0.0:: works, but combine it with a password and a firewall rule — never one without the other.

Step 3: Keep protected-mode and set a password

Leave this line as it is:

protected-mode yes

Then set a password a few lines below:

requirepass 8f3c1d9a4b7e2f60c5a1d8e3b9f4c7a2

Generate one rather than inventing it:

openssl rand -hex 32

While you are in the file, consider disabling dangerous commands for remote clients:

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""

Step 4: Restart Redis and check the listener

sudo systemctl restart redis-server
sudo systemctl status redis-server
ss -tlnp | grep 6379

Expected output shows the new address:

LISTEN 0  511  203.0.113.10:6379  0.0.0.0:*  users:(("redis-server",pid=1421,fd=6))
LISTEN 0  511      127.0.0.1:6379  0.0.0.0:*  users:(("redis-server",pid=1421,fd=7))

If you only see 127.0.0.1, the bind line did not take effect — check for a second bind directive later in the file or an override in /etc/redis/redis.conf.d/.

Step 5: Open port 6379 to the client only

Do not open 6379 to the world. Allow the single client address.

With UFW:

sudo ufw allow from 203.0.113.10 to any port 6379 proto tcp
sudo ufw status numbered

With firewalld:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="6379" protocol="tcp" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-rich-rules

For subnet-wide access, use 203.0.113.0/24 instead. See firewalld rich rules for IP-based access for more patterns.

If your VPS provider has a cloud firewall or security group in front of the server, add the same rule there. A local firewall rule alone will not help if the provider blocks the port upstream.

Step 6: Connect from the remote client

From the client machine:

redis-cli -h 203.0.113.10 -p 6379 -a '8f3c1d9a4b7e2f60c5a1d8e3b9f4c7a2' ping

A working setup returns:

PONG

In application config, the same three values apply — host 203.0.113.10, port 6379, and the password. Most clients call the password option password or auth.

Check it works

Run these from the client, not the server:

1. redis-cli -h 203.0.113.10 -p 6379 -a 'PASSWORD' ping returns PONG.
2. redis-cli -h 203.0.113.10 -p 6379 -a 'PASSWORD' info server | head -n 5 returns the server section, proving commands are accepted.
3. redis-cli -h 203.0.113.10 -p 6379 ping (no password) returns NOAUTH Authentication required. — that confirms the password is enforced.
4. From a machine that is not on the allow list, the connection should time out rather than connect.

On the server, watch the log while you test:

sudo tail -f /var/log/redis/redis-server.log

Troubleshooting

• Could not connect to Redis at 203.0.113.10:6379: Connection refused — Redis is not listening on that address. Recheck the bind line, confirm the service restarted, and run ss -tlnp | grep 6379 to see the real listener.
• DENIED Redis is running in protected mode — bind is still commented out or set to loopback only, and no password is set. Set an explicit bind address and a requirepass value, then restart.
• NOAUTH Authentication required — requirepass is set but the client is not sending it. Add the password to the client config or pass -a on the command line.
• Connection times out with no error — a firewall is dropping the packets. Check UFW or firewalld on the server, then the provider's cloud firewall. sudo ufw status and sudo firewall-cmd --list-all are the first two commands to run.
• Works locally, fails remotely — the listener is fine but the port is closed upstream, or the client is hitting a different IP than the one in bind. Verify with redis-cli -h 127.0.0.1 ping on the server first.

Next steps

• Harden the instance further with how to install and secure Redis on a Linux VPS.
• Tune performance once remote clients are connected: optimizing Redis for high-read, low-latency applications.
• Restrict access by source address with firewalld rich rules for IP-based access.