PostgreSQL: could not connect — Connection refused на порту 5432

#Что означает ошибка

Сообщение «could not connect to server: Connection refused» и вопрос «Is the server running on host … and accepting TCP/IP connections on port 5432?» означают, что по указанному адресу никто не принимает соединения. Это отличается от ошибок аутентификации: до проверки пароля дело не дошло, сервер либо не запущен, либо не слушает нужный интерфейс, либо путь до него закрыт файрволом.

Диагностику стоит начинать с проверки самого сервера на машине, где он установлен, и только затем разбираться с сетью. Так вы быстро определите, где именно оборвана цепочка: служба, конфигурация или сетевой доступ.

Запустите сервер и проверьте listen_addresses и файрвол.

#Причины и решения

#Пошаговое решение

1. Запустите PostgreSQLУбедитесь, что ошибка действительно Connection refused, а не password authentication failed, no pg_hba.conf entry или истечение времени ожидания. В клиенте запишите адрес сервера, номер порта (обычно 5432), имя базы и время. Если подключение удалённое, проверьте, включена ли корпоративная VPN, а затем попробуйте получить ответ от администратора о состоянии сервера. Connection refused обычно означает, что по указанному адресу и порту нет принимающего процесса либо соединение активно отклоняется; настройки pg_hba.conf на этом этапе обычно ещё не проверялись.
2. Проверьте, что сервер слушает портНа сервере, где должен работать PostgreSQL, администратор проверяет службу: в Linux выполните systemctl status postgresql (на Debian с кластерами также pg_lsclusters, если команда доступна), в Windows откройте Win+R → services.msc и найдите службу postgresql-x64-*. Если служба остановлена, выясните причину по журналу и запустите именно нужный экземпляр; не запускайте случайный кластер со старой базой. После запуска повторите подключение к 127.0.0.1 с локального сервера. Если служба не стартует, журнал важнее правки сетевых правил. На Linux в терминале сервера выполните sudo ss -ltnp | grep 5432 (порт замените реальным). Результат вида 127.0.0.1:5432 означает только локальные подключения; 0.0.0.0:5432 — прослушивание всех IPv4-адресов. Если список пуст, узнайте действующий порт и путь конфигурации через локальное подключение к нужному кластеру командой SHOW port; и SHOW config_file;; при невозможности подключения прочитайте журнал службы. В Windows проверить порт можно через PowerShell Get-NetTCPConnection -LocalPort 5432 -State Listen.
3. Разрешите клиента в pg_hba.confЕсли локально всё работает, а удалённое соединение не принимается, администратор проверяет параметры listen_addresses и port в postgresql.conf конкретного экземпляра. Не ставьте listen_addresses='*' по умолчанию: укажите внутренний IP сервера или ограниченный адрес, доступный клиентам. Сохраните прежние значения. Изменение listen_addresses требует перезапуска PostgreSQL, а это прерывает соединения — согласуйте окно обслуживания и резервную копию прежде, чем менять рабочий сервер. После перезапуска повторите ss и убедитесь, что слушается правильный интерфейс.
4. Откройте портТолько после появления слушающего сокета и подтверждения сетевой достижимости проверяйте правила авторизации pg_hba.conf. Это отдельная ошибка, обычно имеющая текст no pg_hba.conf entry. Администратор добавляет адресно ограниченное правило для конкретной базы, роли и подсети с современным методом аутентификации, например SCRAM, если он настроен, затем перечитывает конфигурацию через SELECT pg_reload_conf();. Не открывайте host all all 0.0.0.0/0 trust. При ошибке синтаксиса смотрите журнал PostgreSQL и возвращайте резервную копию конфигурации. Если сервер слушает внешний адрес, проверьте связь с клиентского компьютера: в Windows PowerShell выполните Test-NetConnection -ComputerName ИМЯ_СЕРВЕРА -Port 5432, в Linux при наличии nc — nc -vz ИМЯ_СЕРВЕРА 5432. Имя и порт замените действительными. Если тест не проходит, администратор проверяет межсетевой экран, облачную группу безопасности и маршрутизацию, разрешая доступ только нужной подсети, а не всему Интернету. Если порт доступен, но psql выдаёт ошибку пароля, решайте её отдельно.
5. Проверьте подключениеПосле исправления в терминале клиента выполните psql -h ИМЯ_СЕРВЕРА -p 5432 -U ИМЯ_ПОЛЬЗОВАТЕЛЯ -d ИМЯ_БАЗЫ, заменив все обозначения реальными значениями; пароль вводится в отдельном запросе, не публикуйте его в истории команд. Ожидаемый результат — приглашение имя_базы=>, после чего можно выполнить SELECT current_database(), inet_server_addr();. Если подключение не удалось, сохраните полный текст ошибки, фактический адрес и время и передайте администратору. Не повторяйте изменения конфигурации наугад.

#Сервер не запущен

Проверьте состояние службы командой systemctl status postgresql. Если она остановлена или упала, смотрите журнал (journalctl -u postgresql, файл postgresql-*.log): частые причины — нехватка места на диске, повреждённый файл postmaster.pid после аварийной остановки, несовместимость версий данных после обновления пакета.

#Сервер не слушает внешний адрес

По умолчанию PostgreSQL принимает подключения только с localhost. Чтобы разрешить внешние, задайте в postgresql.conf параметр listen_addresses, а в pg_hba.conf добавьте строку с адресом клиента и методом аутентификации (scram-sha-256). После изменения конфигурации перезапустите службу.

#Файрвол и облачные правила

Откройте порт 5432 только для нужных адресов в ufw, firewalld или облачной группе безопасности. Не публикуйте базу данных во весь интернет: боты ищут открытые PostgreSQL и перебирают пароли. Для удалённой работы безопаснее SSH-туннель или VPN.