Los errores comunes se pueden clasificar a grandes rasgos:

Primero ejecuta esto en el propio VPS:

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

Si el PING local ni siquiera devuelve PONG, diagnostica primero el servicio en sí; si local funciona pero la aplicación o la conexión remota falla, entonces diagnostica la dirección de escucha, el firewall y la autenticación.

En Ubuntu / Debian el nombre de servicio común es redis-server:

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

Si el servicio falla al iniciar, presta atención a estas señales:

• Error de sintaxis en el archivo de configuración;
• El puerto 6379 está ocupado;
• Error de permisos en el directorio de archivos RDB / AOF;
• Disco lleno que impide escribir;
• Memoria insuficiente u OOM;
• Permisos incorrectos del directorio de montaje del volumen de Docker.

Confirma la versión de Redis y la ubicación del archivo de configuración:

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

La documentación oficial de Redis también advierte: Redis puede iniciarse sin archivo de configuración, pero para uso en producción se debe gestionar la configuración mediante redis.conf; los cambios en tiempo de ejecución de CONFIG SET no necesariamente se escriben de vuelta en el archivo de configuración y pueden perderse tras un reinicio.

sudo ss -lntup | grep 6379

Resultados comunes:

127.0.0.1:6379
0.0.0.0:6379

Si solo escucha en 127.0.0.1:6379, solo la máquina local puede conectarse. Para aplicaciones en la misma máquina, este es el estado recomendado; para aplicaciones remotas, se necesita acceso mediante red interna, túnel o lista blanca controlada.

Prueba local:

redis-cli -h 127.0.0.1 -p 6379 ping

Si esto funciona pero el remoto no, el problema suele estar en bind, protected-mode, el firewall, el grupo de seguridad o la autenticación del cliente.

Archivo de configuración común:

/etc/redis/redis.conf

Revisa los elementos clave:

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

Recomendación de seguridad:

bind 127.0.0.1 ::1
protected-mode yes

Si la aplicación y Redis están en el mismo VPS, no lo cambies a 0.0.0.0. Si realmente se necesita acceso entre máquinas, prioriza una IP interna o una red VPN, por ejemplo:

bind 127.0.0.1 10.0.0.8
protected-mode yes

Reinicia tras los cambios:

sudo systemctl restart redis-server

Vuelve a comprobar la escucha:

sudo ss -lntup | grep 6379

Si Redis tiene contraseña habilitada, el cliente debe enviar autenticación. Configuración heredada común:

requirepass 强密码

Redis 6+ también puede usar ACL. Consulta la ACL:

redis-cli ACL LIST

Prueba con contraseña:

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

Una forma más segura es evitar dejar la contraseña en el historial del shell; puedes usar temporalmente variables de entorno o entrada interactiva.

Formato común de cadena de conexión de la aplicación:

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

Si en los registros de la aplicación aparece NOAUTH, significa que Redis requiere autenticación pero el cliente no la envió; si aparece WRONGPASS, la contraseña o el usuario no coinciden.

Firewall local:

sudo ufw status verbose

Si solo se permiten IP de origen fijas:

sudo ufw allow from 203.0.113.10 to any port 6379 proto tcp

No ejecutes a la ligera:

sudo ufw allow 6379/tcp

A menos que ya hayas restringido el origen en el grupo de seguridad de la nube y confirmado que el negocio realmente requiere acceso remoto.

Prueba el puerto desde el cliente:

nc -vz VPS公网IP 6379

Si el puerto no responde, diagnostica primero la capa de red; si el puerto responde pero la autenticación falla, entonces diagnostica la configuración de Redis.

Si Redis se ejecuta en Docker:

docker ps

Comprueba si PORTS contiene:

127.0.0.1:6379->6379/tcp

En producción se recomienda más vincular a localhost:

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

Si el contenedor se reinicia repetidamente, revisa los registros:

docker logs --tail=100 容器名

Los permisos del volumen, los fallos de escritura de AOF/RDB y los límites de memoria demasiado bajos pueden impedir que Redis arranque.

Orden recomendado:

1. redis-cli ping prueba local;
2. systemctl status redis-server revisar el servicio;
3. journalctl -u redis-server -n 100 revisar los registros;
4. ss -lntup | grep 6379 revisar la dirección de escucha;
5. Comprobar bind, protected-mode, requirepass, ACL;
6. Comprobar UFW y los grupos de seguridad de la nube;
7. En escenarios Docker, comprobar ports y los volúmenes;
8. Por último, cambiar la cadena de conexión de la aplicación.

Redis es adecuado para estar junto a la aplicación, no para exponerse directamente a la internet pública. Métodos de conexión más seguros:

• Aplicación en la misma máquina: escuchar en 127.0.0.1;
• Red interna del mismo cloud: escuchar en la IP interna;
• Administración remota: túnel SSH;
• Acceso entre varias máquinas: WireGuard / Tailscale / ZeroTier;
• Diagnóstico temporal: el grupo de seguridad solo permite IP fijas, cerrarlo al terminar.

Lectura adicional:

• No expongas las bases de datos del VPS directamente a la internet pública (2026): cómo hacer seguro el acceso remoto a MySQL, PostgreSQL y Redis
• El servicio del VPS arrancó pero no es accesible desde fuera (2026): cómo diagnosticar puertos, firewall, grupos de seguridad y direcciones de escucha

Cuando Redis no conecta en un VPS, la causa más común no es una sola, sino la combinación de dirección de escucha, protected-mode, autenticación, firewall y cadena de conexión de la aplicación. Empieza con el redis-cli ping local y luego diagnostica capa por capa hasta el acceso remoto. No abras 6379 a toda la red solo para "conectar": una vez que Redis queda expuesto a la internet pública, el riesgo es mucho mayor que un fallo de conexión.