Common errors can be roughly categorized:

First run this on the VPS itself:

redis-cli ping
sudo systemctl status redis-server --no-pager

If local PING doesn't even return PONG, troubleshoot the service itself first; if local works but the application or remote connection fails, then troubleshoot the listening address, firewall, and authentication.

On Ubuntu / Debian the common service name is redis-server:

sudo systemctl status redis-server --no-pager
sudo journalctl -u redis-server -n 100 --no-pager

If the service fails to start, focus on these signals:

• Configuration file syntax error;
• Port 6379 is occupied;
• RDB / AOF file directory permission error;
• Disk full, preventing writes;
• Insufficient memory or OOM;
• Docker volume mount directory permissions incorrect.

Confirm the Redis version and configuration file location:

redis-server --version
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename

Redis official documentation also notes: Redis can start without a configuration file, but for production use you should manage configuration via redis.conf; runtime changes to CONFIG SET are not necessarily written back to the configuration file and may be lost after a restart.

sudo ss -lntup | grep 6379

Common results:

127.0.0.1:6379
0.0.0.0:6379

If it only listens on 127.0.0.1:6379, only the local machine can connect. For applications on the same machine, this is the recommended state; for remote applications, you need access via an internal network, tunnel, or controlled whitelist.

Local test:

redis-cli -h 127.0.0.1 -p 6379 ping

If this works but remote doesn't, the problem is usually in bind, protected-mode, the firewall, security group, or client authentication.

Common configuration file:

/etc/redis/redis.conf

Check the key items:

grep -E '^(bind|protected-mode|requirepass|port)' /etc/redis/redis.conf

Security recommendation:

bind 127.0.0.1 ::1
protected-mode yes

If the application and Redis are on the same VPS, do not change it to 0.0.0.0. If cross-machine access is truly needed, prefer an internal IP or VPN network, for example:

bind 127.0.0.1 10.0.0.8
protected-mode yes

Restart after changes:

sudo systemctl restart redis-server

Check listening again:

sudo ss -lntup | grep 6379

If Redis has a password enabled, the client must send authentication. Common legacy configuration:

requirepass 强密码

Redis 6+ may also use ACL. Check ACL:

redis-cli ACL LIST

Test with password:

redis-cli -a '你的密码' ping

A safer approach is to avoid leaving the password in shell history; you can temporarily use environment variables or interactive input.

Common application connection string format:

redis://:[email protected]:6379/0

If NOAUTH appears in application logs, Redis requires authentication but the client didn't send it; if WRONGPASS appears, the password or user doesn't match.

Local firewall:

sudo ufw status verbose

If only allowing fixed source IPs:

sudo ufw allow from 203.0.113.10 to any port 6379 proto tcp

Do not casually run:

sudo ufw allow 6379/tcp

Unless you have already restricted sources in the cloud security group and confirmed the business truly requires remote access.

Test the port from the client:

nc -vz VPS公网IP 6379

If the port is unreachable, troubleshoot the network layer first; if the port is reachable but authentication fails, then troubleshoot the Redis configuration.

If Redis runs in Docker:

docker ps

Check whether PORTS contains:

127.0.0.1:6379->6379/tcp

For production, binding to localhost is more recommended:

services:
  redis:
    image: redis:7-alpine
    ports:
      - "127.0.0.1:6379:6379"
    command: ["redis-server", "--appendonly", "yes"]
    volumes:
      - redis-data:/data

If the container keeps restarting, check the logs:

docker logs --tail=100 容器名

Volume permissions, AOF/RDB write failures, and low memory limits can all prevent Redis from starting.

Recommended order:

1. redis-cli ping local test;
2. systemctl status redis-server check the service;
3. journalctl -u redis-server -n 100 check the logs;
4. ss -lntup | grep 6379 check the listening address;
5. Check bind, protected-mode, requirepass, ACL;
6. Check UFW and cloud security groups;
7. For Docker scenarios, check ports and volumes;
8. Finally, change the application connection string.

Redis is suited to sit next to the application, not to be exposed directly to the public internet. Safer connection methods:

• Same-machine application: listen on 127.0.0.1;
• Same-cloud internal network: listen on internal IP;
• Remote management: SSH tunnel;
• Multi-machine access: WireGuard / Tailscale / ZeroTier;
• Temporary troubleshooting: security group allows only fixed IPs, close it when done.

Further reading:

• Don't Expose VPS Databases Directly to the Public Internet (2026): How to Make MySQL, PostgreSQL, and Redis Remote Access Secure
• VPS Service Started but Unreachable from Outside (2026): How to Troubleshoot Ports, Firewalls, Security Groups, and Listening Addresses

When Redis won't connect on a VPS, the most common cause is not a single issue but a combination of listening address, protected-mode, authentication, firewall, and application connection string. Start with local redis-cli ping, then troubleshoot layer by layer up to remote access. Don't open 6379 to the whole internet just to "get connected"—once Redis is exposed to the public internet, the risk is far higher than a single connection failure.