Redis bind Explained: Configuring Network Interfaces Securely

Published: 2026-07-17

Introduction

The bind directive determines which network interfaces Redis listens on.

By default, Redis is configured to accept connections only from the local machine. This helps prevent unauthorized remote access and reduces the risk of exposing Redis directly to the Internet.

Choosing the correct bind configuration is an important part of securing any Redis deployment.

This guide explains how the bind directive works, common configuration examples, and best practices for production servers.

Default Value

Most Linux distributions configure Redis with:

bind 127.0.0.1 -::1

bind 127.0.0.1 ::1

This allows Redis to accept connections only from:

IPv4 localhost

IPv6 localhost

Remote clients cannot connect.

Syntax

bind

[address...]

Examples:

bind 127.0.0.1

bind 192.168.1.100

bind 127.0.0.1 192.168.1.100

bind 0.0.0.0

How bind Works

When Redis starts, it listens only on the specified network interfaces.

For example:

bind 127.0.0.1

Only applications running on the same server can connect.

If configured as:

bind 192.168.1.100

Only devices that can reach this private IP address may connect.

If configured as:

bind 0.0.0.0

Redis listens on every available IPv4 interface.

Unless protected by a firewall and authentication, this configuration can expose Redis to untrusted networks.

Configure bind

Open the configuration file.

sudo nano /etc/redis.conf

Example:

bind 127.0.0.1

Restart Redis.

sudo systemctl restart redis

Verify Listening Addresses

Run:

ss -lntp | grep redis

Example output:

LISTEN 0 511 127.0.0.1:6379

LISTEN 0 511 192.168.1.100:6379

You can also verify using:

redis-cli INFO server

Common Configurations

| Configuration      | Description             |
| ------------------ | ----------------------- |
| bind 127.0.0.1     | Local connections only  |
| bind 127.0.0.1 ::1 | IPv4 and IPv6 localhost |
| bind 192.168.x.x   | Private network only    |
| bind 0.0.0.0       | All IPv4 interfaces     |
| bind ::            | All IPv6 interfaces     |

When Should You Use Each Setting?

Local Development

bind 127.0.0.1

Safest choice for development.

Private Internal Network

bind 192.168.1.100

Suitable for application servers connecting over a trusted LAN.

Public Server

Avoid:

bind 0.0.0.0

unless absolutely necessary.

If remote access is required:

Enable authentication.

Use a firewall.

Restrict trusted IP addresses.

Consider VPN access.

Common Mistakes

Using 0.0.0.0 Without Protection

This is one of the most common Redis security mistakes.

Anyone who can reach port 6379 may attempt to connect.

Forgetting the Firewall

Even if bind is configured correctly, firewall rules should also restrict access.

Assuming bind Provides Authentication

The bind directive only controls where Redis listens.

It does not require clients to authenticate.

Best Practices

Use 127.0.0.1 whenever remote access is unnecessary.

Combine bind with requirepass or Redis ACLs.

Restrict access using firewall rules.

Never expose Redis directly to the public Internet unless properly secured.

Regularly verify listening addresses after configuration changes.

Redis Explained

Redis requirepass Explained

Redis maxmemory Explained

Redis appendonly Explained

Redis protected-mode Explained

Conclusion

The bind directive controls which network interfaces Redis listens on and plays a critical role in securing your deployment. In most environments, limiting Redis to localhost or trusted private network addresses is the safest approach.

For production systems that require remote access, always combine bind with authentication, firewall rules, and other security measures to minimize the risk of unauthorized access.

💡 Webmaster Recommendation: Facing network latency or connection drops across Southeast Asia? Try our Global Network Accelerator & Proxy Recommendation to optimize your browsing metrics.