Os erros comuns podem ser classificados de forma geral:

Primeiro execute isto na própria VPS:

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

Se o PING local nem retorna PONG, diagnostique primeiro o próprio serviço; se o local funciona mas a aplicação ou a conexão remota falha, então diagnostique o endereço de escuta, o firewall e a autenticação.

No Ubuntu / Debian o nome de serviço comum é redis-server:

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

Se o serviço falha ao iniciar, preste atenção a estes sinais:

• Erro de sintaxe no arquivo de configuração;
• A porta 6379 está ocupada;
• Erro de permissão no diretório dos arquivos RDB / AOF;
• Disco cheio impedindo a escrita;
• Memória insuficiente ou OOM;
• Permissões incorretas do diretório de montagem do volume do Docker.

Confirme a versão do Redis e o local do arquivo de configuração:

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

A documentação oficial do Redis também alerta: o Redis pode iniciar sem arquivo de configuração, mas para uso em produção a configuração deve ser gerenciada via redis.conf; alterações em tempo de execução em CONFIG SET não são necessariamente gravadas de volta no arquivo de configuração e podem ser perdidas após um reinício.

sudo ss -lntup | grep 6379

Resultados comuns:

127.0.0.1:6379
0.0.0.0:6379

Se escuta apenas em 127.0.0.1:6379, somente a máquina local consegue conectar. Para aplicações na mesma máquina, este é o estado recomendado; para aplicações remotas, é necessário acesso via rede interna, túnel ou lista de permissões controlada.

Teste local:

redis-cli -h 127.0.0.1 -p 6379 ping

Se isto funciona mas o remoto não, o problema geralmente está em bind, protected-mode, no firewall, no security group ou na autenticação do cliente.

Arquivo de configuração comum:

/etc/redis/redis.conf

Verifique os itens principais:

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

Recomendação de segurança:

bind 127.0.0.1 ::1
protected-mode yes

Se a aplicação e o Redis estão na mesma VPS, não altere para 0.0.0.0. Se realmente for necessário acesso entre máquinas, prefira um IP interno ou uma rede VPN, por exemplo:

bind 127.0.0.1 10.0.0.8
protected-mode yes

Reinicie após as alterações:

sudo systemctl restart redis-server

Verifique a escuta novamente:

sudo ss -lntup | grep 6379

Se o Redis tem senha habilitada, o cliente precisa enviar autenticação. Configuração legada comum:

requirepass 强密码

O Redis 6+ também pode usar ACL. Consulte a ACL:

redis-cli ACL LIST

Teste com senha:

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

Uma forma mais segura é evitar deixar a senha no histórico do shell; você pode usar temporariamente variáveis de ambiente ou entrada interativa.

Formato comum da string de conexão da aplicação:

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

Se NOAUTH aparecer nos logs da aplicação, significa que o Redis exige autenticação mas o cliente não a enviou; se aparecer WRONGPASS, a senha ou o usuário não coincidem.

Firewall local:

sudo ufw status verbose

Se permitir apenas IPs de origem fixos:

sudo ufw allow from 203.0.113.10 to any port 6379 proto tcp

Não execute sem pensar:

sudo ufw allow 6379/tcp

A menos que você já tenha restringido a origem no security group da nuvem e confirmado que o negócio realmente exige acesso remoto.

Teste a porta a partir do cliente:

nc -vz VPS公网IP 6379

Se a porta não responde, diagnostique primeiro a camada de rede; se a porta responde mas a autenticação falha, então diagnostique a configuração do Redis.

Se o Redis roda em Docker:

docker ps

Verifique se PORTS contém:

127.0.0.1:6379->6379/tcp

Em produção, recomenda-se mais vincular ao localhost:

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

Se o contêiner reinicia repetidamente, verifique os logs:

docker logs --tail=100 容器名

Permissões do volume, falhas de escrita de AOF/RDB e limites de memória muito baixos podem impedir o Redis de iniciar.

Ordem recomendada:

1. redis-cli ping teste local;
2. systemctl status redis-server verificar o serviço;
3. journalctl -u redis-server -n 100 verificar os logs;
4. ss -lntup | grep 6379 verificar o endereço de escuta;
5. Verificar bind, protected-mode, requirepass, ACL;
6. Verificar UFW e security groups da nuvem;
7. Em cenários Docker, verificar ports e volumes;
8. Por último, alterar a string de conexão da aplicação.

O Redis é adequado para ficar ao lado da aplicação, não para ser exposto diretamente à internet pública. Métodos de conexão mais seguros:

• Aplicação na mesma máquina: escutar em 127.0.0.1;
• Rede interna da mesma nuvem: escutar no IP interno;
• Administração remota: túnel SSH;
• Acesso entre várias máquinas: WireGuard / Tailscale / ZeroTier;
• Diagnóstico temporário: o security group libera apenas IPs fixos, fechar ao terminar.

Leitura complementar:

• Não exponha os bancos de dados da VPS diretamente à internet pública (2026): como tornar seguro o acesso remoto ao MySQL, PostgreSQL e Redis
• O serviço da VPS iniciou mas não é acessível de fora (2026): como diagnosticar portas, firewall, security groups e endereços de escuta

Quando o Redis não conecta em uma VPS, a causa mais comum não é uma só, mas a combinação de endereço de escuta, protected-mode, autenticação, firewall e string de conexão da aplicação. Comece pelo redis-cli ping local e depois diagnostique camada por camada até o acesso remoto. Não abra a 6379 para toda a rede só para "conectar": uma vez que o Redis fica exposto à internet pública, o risco é muito maior do que uma falha de conexão.