Ошибка 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 {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 не стоит сразу копать конфиги. Сначала проверить базовые вещи: запущен ли сервис, слушает ли порт и доступен ли сервер по сети.