Could not connect to server: как понять причину и быстро починить

Ошибка could not connect to server в PostgreSQL — возникает если клиент вообще не смог установить соединение с сервером.

Есть несколько вариантов этой ошибки — уточнение позволяет быстрее понять причины.

  • psql: could not connect to server: Connection refused — по адресу есть ответ, но соединение отклонено
  • psql: could not connect to server: Operation timed out — ответа вообще нет
  • psql: could not connect to server: No route to host — до хоста не удаётся добраться на уровне сети

Диагностируем «could not connect to server»

Обычно проблему можно найти за пару минут с помощью набора команд


systemctl status postgresql -- запущен ли PostgreSQL

ss -ltnp | grep 5432 -- слушает ли порт 5432

nc -zv {host} 5432 -- открыт ли порт 5432

ping {host} -- доступен ли сервер

На каком шаге всё ломается — там и причина.

Разберём типы ошибки подробнее

1. Connection refused

Самый частый вариант. Сервер доступен, но порт не принимает соединения. Обычно это значит следующее:

  • PostgreSQL не запущен
  • он не настроен на нужный сервер (например, только localhost)
  • порт отличается от 5432
Как проверить:

systemctl status postgresql -- посмотреть статус

systemctl start postgresql -- запустить PostgreSQL

ss -ltnp | grep 5432 -- проверить порт

Если сервер слушает только localhost, снаружи к нему не подключиться.

2. Operation timed out

В этом случае вообще нет ответа. Чаще всего это бывает если сервер недоступен по сети, сработал firewall (не пропустил соединение), или порт просто «молча» дропается

3. No route to host

Это проблема на уровне сети. Пакеты не доходят до сервера.

Причины:

  • неверный IP или hostname
  • ошибка в маршрутизации
  • сервер в другой сети без доступа
ping не всегда может показать проблему, но проверить стоит:

ping {host}

Проверка конфигурации PostgreSQL

В файле конфигурации postgresql.conf есть параметр listen_addresses. Если там указано listen_addresses = 'localhost' — это значит что сервер принимает только локальные подключения. Чтобы подключиться извне, нужно указать конкретный IP или '*' (это позволяет подключаться от любого IP, так настоятельно не рекомендуется делать в прод окружении)

Проблемы вызванные firewall

Блокировка IP или порта может быть не на уровне PostgreSQL, а на уровне системы. Если в конфигах базы всё в порядке стоит проверить ufw / iptables на сервере, а также настройки провайдера.

Если PostgreSQL запущен в Docker

Этот случай стоит рассмотреть отдельно т.к. эта практика встречается всё чаще. Когда база работает внутри контейнера у нас появляется ещё один "уровень" — порт может быть открыт в контейнере, но недоступен снаружи. В этом случае надо проверить проброшен ли порт из контейнера наружу и слушает ли PostgreSQL внутри контейнера не только localhost.

Проверка проброса портов:

docker ps

0.0.0.0:5432->5432/tcp -- пример колонки PORTS.

    

Если в PORTS только 5432/tcp — порт не опубликован наружу. Это можно исправить выполнив в консоли docker run -p 5432:5432 postgres, но лучше добавить в docker-compose:


services:
  db:
    image: postgres
    ports:
      - "5432:5432"

    

Если PostgreSQL внутри контейнера слушает только localhost, то даже при проброшенном порте подключение снаружи не сработает. В этом случае нужно будет проверить конфигурацию PostgreSQL внутри контейнера.

Логи

При connection refused или timeout, вряд ли в логах что-то будет, так как при этих ошибках до сервера просто не дошли. Но если соединение прошло, то чаще всего логи хранятся в /var/log/postgresql/postgresql-*.log

Получив ошибку could not connect to server не стоит сразу копать конфиги. Сначала проверить базовые вещи: запущен ли сервис, слушает ли порт и доступен ли сервер по сети.