How to Fix Redis on Linux Server When It Refuses Connections

To fix Redis on a Linux server, start by checking whether the service is running, reviewing its logs, and validating the configuration. Then address common issues such as port binding, firewall, memory limits, persistence errors, and kernel tuning. Finally, harden and monitor Redis with best practices to prevent repeat incidents and improve performance.

Redis issues can bring applications to a halt. In this guide, you’ll learn how to fix Redis on a Linux server step by step, from quick diagnostics to deep troubleshooting, plus configuration best practices for reliable, fast performance.

The instructions cover Debian/Ubuntu and RHEL/CentOS families and work whether you run standalone Redis, with Sentinel, or as part of a cluster.

---

Quick Diagnosis Checklist

Run these quick checks to pinpoint the root cause before changing anything. Keep notes on what you find.

• Is the service active?

sudo systemctl status redis
# On Debian/Ubuntu it may be:
sudo systemctl status redis-server

# View recent logs:
sudo journalctl -u redis -e --no-pager

• Can you connect and ping?

redis-cli -h 127.0.0.1 -p 6379 ping
# Expect: PONG
redis-cli -s /var/run/redis/redis-server.sock ping  # if using a UNIX socket

• Is Redis listening on the expected interface and port?

ss -ltnp | grep 6379
sudo tail -n 200 /var/log/redis/redis-server.log  # Debian/Ubuntu
sudo tail -n 200 /var/log/redis/redis.log         # RHEL/CentOS

• Any recent config changes?

sudo grep -E '^(bind|port|protected-mode|maxmemory|appendonly|save|daemonize|tcp-backlog|requirepass|aclfile)' \
/etc/redis/redis.conf 2>/dev/null || sudo grep -E '^(bind|port|...)' /etc/redis.conf

---

Common Redis Errors and How to Fix Them

1) Redis service won’t start

Symptoms: systemctl status shows failed, logs show config errors, or permission issues on data/log directories.

• Validate the configuration path and syntax

# Run Redis in foreground to surface errors immediately:
sudo -u redis redis-server /etc/redis/redis.conf --daemonize no

• Fix bind/protected mode for local testing

# In /etc/redis/redis.conf (or /etc/redis.conf):
bind 127.0.0.1
protected-mode yes
port 6379
supervised systemd
daemonize no  # when using systemd

# Then:
sudo systemctl daemon-reload
sudo systemctl restart redis || sudo systemctl restart redis-server

• Ensure directories are writable by the redis user

sudo mkdir -p /var/lib/redis /var/log/redis
sudo chown -R redis:redis /var/lib/redis /var/log/redis
sudo chmod 770 /var/lib/redis /var/log/redis

• Firewalls and SELinux

# UFW
sudo ufw allow 6379/tcp

# firewalld
sudo firewall-cmd --permanent --add-port=6379/tcp && sudo firewall-cmd --reload

# SELinux (allow Redis on 6379 if needed):
sudo semanage port -a -t redis_port_t -p tcp 6379 2>/dev/null || \
sudo semanage port -m -t redis_port_t -p tcp 6379

2) “Connection refused” or timeouts

Usually caused by binding to the wrong interface, blocked port, or Redis not listening at all.

• Ensure Redis is listening:

ss -ltnp | grep 6379
# If not listening, check bind/port in redis.conf and restart the service

• Fix over-aggressive kernel backlog warnings

# If you see: "WARNING The TCP backlog setting ... cannot be enforced"
echo "net.core.somaxconn = 65535" | sudo tee /etc/sysctl.d/99-redis.conf
sudo sysctl --system

# Also set in redis.conf:
tcp-backlog 65535

• Network path
• Verify security groups, load balancer health checks, or Kubernetes services if applicable.

3) Out of memory or OOM errors

You may see “OOM command not allowed when used memory > ‘maxmemory’” or the Linux OOM killer terminating the Redis process.

• Set a safe memory cap and an eviction policy

# In redis.conf:
maxmemory 2gb
maxmemory-policy allkeys-lru  # or volatile-lru, volatile-ttl, noeviction, etc.

• Enable overcommit and disable Transparent Huge Pages (recommended by Redis)

# Overcommit:
echo "vm.overcommit_memory = 1" | sudo tee /etc/sysctl.d/99-redis-memory.conf
sudo sysctl --system

# Disable THP (temporary until reboot):
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

For a permanent THP fix, create a small systemd unit to disable THP at boot, or add the commands to your rc.local startup.

4) AOF/RDB persistence errors or corruption

Symptoms include “Background saving error” or “MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk”. Often caused by disk full, permission issues, or corrupted files.

• Check disk and I/O

df -h
iostat -xz 1 3  # if sysstat is installed
sudo dmesg | tail -n 50

• Temporarily allow writes if blocked by snapshot errors (use with caution)

redis-cli CONFIG SET stop-writes-on-bgsave-error no

• Repair corrupted files safely

sudo systemctl stop redis || sudo systemctl stop redis-server
cd /var/lib/redis
sudo cp appendonly.aof appendonly.aof.bak 2>/dev/null || true
sudo cp dump.rdb dump.rdb.bak 2>/dev/null || true

# Repair:
sudo redis-check-aof --fix appendonly.aof 2>/dev/null || true
sudo redis-check-rdb dump.rdb 2>/dev/null || true

sudo systemctl start redis || sudo systemctl start redis-server

• Safer persistence defaults

# In redis.conf:
appendonly yes
appendfsync everysec
no-appendfsync-on-rewrite yes
save 900 1
save 300 10
save 60 10000

5) High CPU or latency spikes

• Find slow operations

redis-cli SLOWLOG GET 20
redis-cli --latency
redis-cli INFO commandstats | head

• Common fixes
• Use a UNIX socket for localhost clients.
• Scale read load with replicas or shards.
• Avoid large blocking operations (e.g., massive KEYS or big Lua scripts).
• Use pipelining and proper data structures for batch workloads.

---

Configuration Best Practices for Production

System-level tuning

# /etc/sysctl.d/99-redis.conf
vm.overcommit_memory = 1
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
# Apply:
sudo sysctl --system

# Increase file descriptors for the service
sudo systemctl edit redis  # or redis-server

# Add the following under [Service] in the drop-in:
[Service]
LimitNOFILE=100000
Restart=on-failure
RestartSec=2

# Save and reload:
sudo systemctl daemon-reload
sudo systemctl restart redis || sudo systemctl restart redis-server

redis.conf essentials

• supervised systemd
• daemonize no (when managed by systemd)
• bind 127.0.0.1 and/or a private IP; avoid 0.0.0.0 unless firewalled
• protected-mode yes
• Authentication via requirepass or ACLs
• maxmemory with an eviction policy
• appendonly yes and appendfsync everysec
• tcp-backlog 65535

supervised systemd
daemonize no
bind 127.0.0.1
protected-mode yes
requirepass <strong-secret>  # or configure ACLs
maxmemory 70%_of_RAM
maxmemory-policy allkeys-lru
appendonly yes
appendfsync everysec
tcp-backlog 65535

Security basics

• Never expose Redis directly to the public Internet.
• Restrict by firewall and bind to private interfaces.
• Use strong passwords or ACLs; consider stunnel or TLS if traffic crosses untrusted networks.
• Rename dangerous commands (FLUSHALL, CONFIG, KEYS) if needed.

# In redis.conf
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS "KEYS__DISABLED"

---

Step-by-Step Recovery Workflow

• Snapshot and backup
• Copy current dump.rdb and appendonly.aof before any repair. Take VM or volume snapshots if available.
• Quarantine traffic
• Temporarily stop application traffic or drain connections via your load balancer while you fix the instance.
• Fix and validate offline
• Start Redis in the foreground on a different port to validate config and data integrity.
• Re-enable traffic
• After stability and health checks, switch traffic back and monitor closely for spikes and errors.

# Test Redis with current config on a high port (example 6380):
sudo -u redis redis-server /etc/redis/redis.conf --port 6380 --daemonize no

# If all good, stop and start via systemd on the normal port:
# Ctrl+C to stop foreground, then:
sudo systemctl restart redis || sudo systemctl restart redis-server

Monitoring and Preventing Future Incidents

• Key metrics and alerts
• used_memory, used_memory_peak, mem_fragmentation_ratio
• connected_clients, blocked_clients
• rdb_last_bgsave_status, aof_last_bgrewrite_status
• evicted_keys, expired_keys, rejected_connections
• master_link_status, sync_full for replicas

• Tools to use
• Prometheus + Redis Exporter and Grafana dashboards
• Failover with Redis Sentinel or managed orchestrations
• Systemd automatic restarts and log forwarding

# Helpful runbook commands
redis-cli INFO | egrep 'used_memory|mem_fragmentation|evicted|blocked_clients'
redis-cli LATENCY DOCTOR
redis-cli SLOWLOG GET 10

---

When to Scale or Go Managed

If you regularly hit memory limits, see frequent evictions, or experience latency under load, consider vertical scaling, read replicas, sharding, or a managed setup. YouStable’s Managed VPS and Cloud servers include performance tuning, proactive monitoring, and 24×7 support for Redis, so you can focus on your application instead of firefighting infrastructure.

Practical Fix Scenarios

Fix “WARNING overcommit_memory is set to 0”

echo "vm.overcommit_memory = 1" | sudo tee /etc/sysctl.d/99-redis-memory.conf
sudo sysctl --system
sudo systemctl restart redis || sudo systemctl restart redis-server

Fix “MISCONF … not able to persist on disk”

# Free disk space or fix permissions, then:
redis-cli CONFIG SET stop-writes-on-bgsave-error no
# After resolving root cause, set it back to:
redis-cli CONFIG SET stop-writes-on-bgsave-error yes

Safely flush a broken cache without losing persistent data

Only if Redis is used purely as a cache and not a primary database, you can flush keys to recover quickly. Confirm with your team before running flush commands.

# DANGER: This clears data. Use only if Redis is a cache.
redis-cli FLUSHALL

---

FAQ’s