Os problemas de conexão do PostgreSQL se dividem aproximadamente em quatro categorias:

Não altere a configuração ainda. Primeiro execute isto na própria VPS:

sudo systemctl status postgresql --no-pager
sudo pg_isready

Se não estiver pronto localmente, solucione primeiro a inicialização do serviço; se funcionar localmente mas não remotamente, então solucione o endereço de escuta, o firewall e o pg_hba.conf.

O PostgreSQL instalado a partir de pacotes no Ubuntu / Debian normalmente é gerenciado pelo systemd:

sudo systemctl status postgresql --no-pager

Verifique os logs recentes:

sudo journalctl -u postgresql -n 100 --no-pager

Dependendo da versão, você também pode verificar uma instância específica:

pg_lsclusters

Na saída, observe:

• Se o Status está online;
• Se o Port é 5432 ou sua porta personalizada;
• Se o Data directory está correto;
• Onde está o caminho do arquivo de log.

Se o serviço falhar ao iniciar, as causas comuns incluem:

• Permissões incorretas no diretório de dados;
• A porta já está ocupada por outra instância do PostgreSQL;
• Disco cheio ou inodes esgotados;
• Erros de sintaxe no arquivo de configuração;
• Memória compartilhada, número de conexões ou parâmetros do kernel configurados muito altos.

A documentação oficial do PostgreSQL também afirma explicitamente que, em caso de falha de inicialização, deve-se verificar os logs primeiro; por exemplo, quando a porta está ocupada você verá algo como Address already in use, e quando a conexão falhar o cliente verá Connection refused.

O serviço aparecer como running não significa que as conexões remotas necessariamente funcionarão. Continue verificando a porta de escuta:

sudo ss -lntup | grep 5432

Há duas saídas comuns:

127.0.0.1:5432
0.0.0.0:5432

Se escutar apenas em 127.0.0.1:5432, o PostgreSQL aceita somente conexões locais. Quando um cliente remoto acessa o IP público da VPS, naturalmente falhará.

Você também pode testar localmente:

psql -h 127.0.0.1 -U postgres -d postgres

Se as conexões locais funcionarem, o problema provavelmente está na escuta remota, no firewall, no grupo de segurança ou no pg_hba.conf.

O PostgreSQL por padrão normalmente escuta apenas localmente. Você pode encontrar a localização do arquivo de configuração assim:

sudo -u postgres psql -c "SHOW config_file;"

Faça backup antes de editar a configuração:

sudo cp /etc/postgresql/*/main/postgresql.conf /etc/postgresql/postgresql.conf.bak.$(date +%F-%H%M) 2>/dev/null || true

Verifique o valor atual:

sudo -u postgres psql -c "SHOW listen_addresses;"

Se você realmente precisa de acesso remoto, é melhor vincular a um endereço de rede interna ou a um endereço específico em vez de escrever * diretamente. Por exemplo:

listen_addresses = '127.0.0.1,10.0.0.5'

Se sua VPS não tem rede interna e você só pode permitir acesso público temporário, também deve combiná-lo com um pg_hba.conf rigoroso e uma lista de permissões do grupo de segurança. Não exponha o banco de dados para toda a internet.

Reinicie após modificar:

sudo systemctl restart postgresql

Verifique novamente:

sudo ss -lntup | grep 5432

O listen_addresses determina se o PostgreSQL escuta em um determinado endereço, enquanto o pg_hba.conf determina quais clientes podem se autenticar e como.

Encontre a localização do arquivo:

sudo -u postgres psql -c "SHOW hba_file;"

Faça backup antes de editar:

sudo cp /etc/postgresql/*/main/pg_hba.conf /etc/postgresql/pg_hba.conf.bak.$(date +%F-%H%M) 2>/dev/null || true

Uma regra de acesso remoto mais segura deve restringir o IP de origem, por exemplo permitir apenas o IP público do seu escritório:

host    mydb    myuser    203.0.113.10/32    scram-sha-256

Não é recomendado fazer assim:

host    all     all       0.0.0.0/0          md5

Ele não apenas abrange um intervalo amplo demais, mas também pode usar um método de autenticação mais antigo. A documentação do PostgreSQL também enfatiza que o pg_hba.conf é correspondido em ordem e a primeira regra correspondente é aplicada; se nenhuma regra corresponder, a conexão é rejeitada.

Após modificar, você pode recarregar:

sudo systemctl reload postgresql

Ou:

sudo -u postgres psql -c "SELECT pg_reload_conf();"

Se você suspeitar de um problema de sintaxe nas regras, verifique com:

sudo -u postgres psql -c "SELECT * FROM pg_hba_file_rules WHERE error IS NOT NULL;"

As conexões remotas não precisam apenas que a porta esteja acessível; o usuário também precisa de permissão para se conectar ao banco de dados correspondente.

Entre no PostgreSQL:

sudo -u postgres psql

Veja os roles:

\du

Exemplo de criação de um usuário de negócio:

CREATE USER appuser WITH PASSWORD '替换为强密码';
CREATE DATABASE appdb OWNER appuser;
GRANT CONNECT ON DATABASE appdb TO appuser;

Teste a conexão:

psql -h 127.0.0.1 -U appuser -d appdb

Se conectar localmente mas não remotamente, continue verificando o firewall e o grupo de segurança.

UFW local:

sudo ufw status verbose

Se você quiser permitir apenas um IP específico:

sudo ufw allow from 203.0.113.10 to any port 5432 proto tcp

Não faça isso diretamente:

sudo ufw allow 5432/tcp

A menos que você tenha muita certeza de que o grupo de segurança da nuvem já restringe o IP de origem.

Verifique também o grupo de segurança ou o firewall no console do provedor de nuvem. Muitos usuários de VPS alteram apenas o UFW dentro do sistema, mas esquecem que o grupo de segurança do console ainda bloqueia a 5432.

Teste a porta a partir do cliente:

nc -vz 你的VPS公网IP 5432

Se a porta não estiver acessível, solucione primeiro a camada de rede; se a porta estiver acessível mas a autenticação falhar, volte para a camada de configuração do PostgreSQL.

Se o PostgreSQL estiver rodando no Docker, verifique também se a porta do contêiner está mapeada para o host:

docker ps

Você precisa ver algo como:

0.0.0.0:5432->5432/tcp

Se houver apenas 5432/tcp dentro do contêiner, mas sem mapeamento no host, não será possível acessar de fora.

Exemplo de Docker Compose:

services:
  postgres:
    image: postgres:16
    ports:
      - "127.0.0.1:5432:5432"
    environment:
      POSTGRES_DB: appdb
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: "替换为强密码"

Em produção, é mais recomendado vincular a 127.0.0.1 para que a aplicação acesse na mesma máquina, ou acessar via rede interna/VPN/host bastião, em vez de expor o banco de dados diretamente à internet.

Recomenda-se seguir esta ordem:

1. systemctl status postgresql para verificar o serviço;
2. journalctl -u postgresql -n 100 para verificar erros de inicialização;
3. pg_lsclusters para verificar a versão, a porta e o diretório de dados;
4. ss -lntup | grep 5432 para verificar o endereço de escuta;
5. SHOW listen_addresses; para verificar se a escuta remota é permitida;
6. SHOW hba_file; para verificar o pg_hba.conf;
7. Use pg_hba_file_rules para verificar erros nas regras;
8. Verifique usuários, bancos de dados e permissões do CONNECT;
9. Verifique o UFW e o grupo de segurança da nuvem;
10. Por fim, verifique o mapeamento de portas do Docker ou a string de conexão da aplicação.

A vantagem de solucionar problemas dessa forma é que cada etapa reduz o escopo, evitando misturar problemas de escuta, autenticação, firewall e senha.

Mesmo que você já tenha corrigido o problema de conexão, isso não significa que você deva expor a 5432 a longo prazo. As práticas mais seguras são:

• Aplicação e banco de dados na mesma VPS: escutar em 127.0.0.1;
• Aplicação e banco de dados na rede interna do mesmo provedor de nuvem: escutar apenas no IP interno;
• Administração remota: usar um túnel SSH;
• Acesso a partir de vários servidores: usar WireGuard / Tailscale / ZeroTier;
• Solução de problemas temporária: permitir apenas seu IP fixo no grupo de segurança e fechar quando terminar.

Você pode consultar este artigo sobre segurança de bancos de dados:

• Não exponha os bancos de dados da VPS diretamente à internet (2026): como fazer o acesso remoto ao MySQL, PostgreSQL e Redis com segurança

Quando o PostgreSQL em uma VPS não conecta, as três coisas mais facilmente confundidas são: se a porta está escutando, se o pg_hba.conf permite e se a camada de rede libera. O Connection refused geralmente é um problema de serviço ou de escuta; o no pg_hba.conf entry é um problema de regras de autenticação; os tempos esgotados de conexão se parecem mais com um problema de firewall, grupo de segurança ou caminho de rede.

Comece a solucionar problemas localmente primeiro e depois avance camada por camada em direção ao acesso remoto. Não abra o listen_addresses='*' e o 0.0.0.0/0 de imediato. Problemas de conectividade do banco de dados podem ser corrigidos, mas o risco de expor um banco de dados à internet costuma ser mais problemático do que a própria falha de conexão.