Los problemas de conexión de PostgreSQL se dividen aproximadamente en cuatro categorías:

No cambies la configuración todavía. Primero ejecuta esto en el propio VPS:

sudo systemctl status postgresql --no-pager
sudo pg_isready

Si no está listo localmente, soluciona primero el inicio del servicio; si funciona localmente pero no de forma remota, entonces soluciona la dirección de escucha, el firewall y pg_hba.conf.

PostgreSQL instalado desde paquetes en Ubuntu / Debian normalmente se gestiona con systemd:

sudo systemctl status postgresql --no-pager

Revisa los registros recientes:

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

Según la versión, también puedes revisar una instancia específica:

pg_lsclusters

En la salida, fíjate en:

• Si Status está online;
• Si Port es 5432 o tu puerto personalizado;
• Si Data directory es correcto;
• Dónde está la ruta del archivo de registro.

Si el servicio falla al iniciar, las causas comunes incluyen:

• Permisos incorrectos en el directorio de datos;
• El puerto ya está ocupado por otra instancia de PostgreSQL;
• Disco lleno o inodos agotados;
• Errores de sintaxis en el archivo de configuración;
• Memoria compartida, número de conexiones o parámetros del kernel configurados demasiado altos.

La documentación oficial de PostgreSQL también indica explícitamente que ante un fallo de inicio se deben revisar primero los registros; por ejemplo, cuando el puerto está ocupado verás algo como Address already in use, y cuando la conexión falla el cliente verá Connection refused.

Que el servicio muestre running no significa que las conexiones remotas vayan a funcionar necesariamente. Continúa revisando el puerto de escucha:

sudo ss -lntup | grep 5432

Hay dos salidas comunes:

127.0.0.1:5432
0.0.0.0:5432

Si solo escucha en 127.0.0.1:5432, PostgreSQL solo acepta conexiones locales. Cuando un cliente remoto accede a la IP pública del VPS, naturalmente fallará.

También puedes probar localmente:

psql -h 127.0.0.1 -U postgres -d postgres

Si las conexiones locales funcionan, el problema es más probable en la escucha remota, el firewall, el grupo de seguridad o pg_hba.conf.

PostgreSQL por defecto normalmente solo escucha localmente. Puedes encontrar la ubicación del archivo de configuración así:

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

Haz una copia de seguridad antes de editar la configuración:

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

Consulta el valor actual:

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

Si realmente necesitas acceso remoto, es mejor vincular a una dirección de red interna o a una dirección específica en lugar de escribir * directamente. Por ejemplo:

listen_addresses = '127.0.0.1,10.0.0.5'

Si tu VPS no tiene red interna y solo puedes permitir acceso público temporal, también debes combinarlo con un pg_hba.conf estricto y una lista de permitidos del grupo de seguridad. No expongas la base de datos a todo internet.

Reinicia después de modificar:

sudo systemctl restart postgresql

Comprueba de nuevo:

sudo ss -lntup | grep 5432

listen_addresses determina si PostgreSQL escucha en una dirección determinada, mientras que pg_hba.conf determina qué clientes pueden autenticarse y cómo.

Encuentra la ubicación del archivo:

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

Haz una copia de seguridad 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

Una regla de acceso remoto más segura debería restringir la IP de origen, por ejemplo permitir solo la IP pública de tu oficina:

host    mydb    myuser    203.0.113.10/32    scram-sha-256

No se recomienda esto:

host    all     all       0.0.0.0/0          md5

No solo abarca un rango demasiado amplio, sino que además puede usar un método de autenticación más antiguo. La documentación de PostgreSQL también enfatiza que pg_hba.conf se compara en orden y la primera regla coincidente es la que se aplica; si ninguna regla coincide, se rechaza la conexión.

Después de modificar, puedes recargar:

sudo systemctl reload postgresql

O:

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

Si sospechas que hay un problema de sintaxis en las reglas, compruébalo con:

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

Las conexiones remotas no solo necesitan que el puerto sea accesible; el usuario también necesita permiso para conectarse a la base de datos correspondiente.

Entra en PostgreSQL:

sudo -u postgres psql

Consulta los roles:

\du

Ejemplo de creación de un usuario de negocio:

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

Prueba la conexión:

psql -h 127.0.0.1 -U appuser -d appdb

Si conecta localmente pero no de forma remota, continúa revisando el firewall y el grupo de seguridad.

UFW local:

sudo ufw status verbose

Si solo quieres permitir una IP específica:

sudo ufw allow from 203.0.113.10 to any port 5432 proto tcp

No hagas esto directamente:

sudo ufw allow 5432/tcp

A menos que estés muy seguro de que el grupo de seguridad en la nube ya restringe la IP de origen.

También revisa el grupo de seguridad o el firewall en la consola del proveedor de nube. Muchos usuarios de VPS solo cambian UFW dentro del sistema pero olvidan que el grupo de seguridad de la consola sigue bloqueando el 5432.

Prueba el puerto desde el cliente:

nc -vz 你的VPS公网IP 5432

Si el puerto no es accesible, soluciona primero la capa de red; si el puerto es accesible pero la autenticación falla, vuelve a la capa de configuración de PostgreSQL.

Si PostgreSQL se ejecuta en Docker, también debes comprobar si el puerto del contenedor está mapeado al host:

docker ps

Necesitas ver algo como:

0.0.0.0:5432->5432/tcp

Si solo hay 5432/tcp dentro del contenedor pero no hay mapeo en el host, no se puede acceder desde fuera.

Ejemplo de Docker Compose:

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

En producción se recomienda más vincular a 127.0.0.1 para que la aplicación acceda en la misma máquina, o acceder mediante red interna/VPN/host de bastión, en lugar de exponer la base de datos directamente a internet.

Se recomienda seguir este orden:

1. systemctl status postgresql para revisar el servicio;
2. journalctl -u postgresql -n 100 para revisar errores de inicio;
3. pg_lsclusters para revisar la versión, el puerto y el directorio de datos;
4. ss -lntup | grep 5432 para revisar la dirección de escucha;
5. SHOW listen_addresses; para revisar si se permite la escucha remota;
6. SHOW hba_file; para revisar pg_hba.conf;
7. Usa pg_hba_file_rules para comprobar errores en las reglas;
8. Revisa usuarios, bases de datos y permisos de CONNECT;
9. Revisa UFW y el grupo de seguridad en la nube;
10. Por último, revisa el mapeo de puertos de Docker o la cadena de conexión de la aplicación.

La ventaja de solucionar problemas de esta manera es que cada paso reduce el alcance, evitando mezclar problemas de escucha, autenticación, firewall y contraseña.

Aunque ya hayas solucionado el problema de conexión, eso no significa que debas exponer el 5432 a largo plazo. Las prácticas más seguras son:

• Aplicación y base de datos en el mismo VPS: escuchar en 127.0.0.1;
• Aplicación y base de datos en la red interna del mismo proveedor de nube: escuchar solo en la IP interna;
• Administración remota: usar un túnel SSH;
• Acceso desde varios servidores: usar WireGuard / Tailscale / ZeroTier;
• Solución de problemas temporal: permitir solo tu IP fija en el grupo de seguridad y cerrarlo cuando termines.

Puedes consultar este artículo sobre seguridad de bases de datos:

• No expongas las bases de datos del VPS directamente a internet (2026): cómo hacer el acceso remoto a MySQL, PostgreSQL y Redis de forma segura

Cuando PostgreSQL en un VPS no conecta, las tres cosas que más se confunden son: si el puerto está escuchando, si pg_hba.conf lo permite y si la capa de red lo permite. Connection refused suele ser un problema de servicio o de escucha; no pg_hba.conf entry es un problema de reglas de autenticación; los tiempos de espera de conexión se parecen más a un problema de firewall, grupo de seguridad o ruta de red.

Empieza a solucionar problemas localmente primero y luego avanza capa por capa hacia el acceso remoto. No abras listen_addresses='*' y 0.0.0.0/0 de inmediato. Los problemas de conectividad de la base de datos se pueden corregir, pero el riesgo de exponer una base de datos a internet suele ser más problemático que el propio fallo de conexión.