PostgreSQL: не принимает подключения — причины и решение

MAATRIX

Приложение не может достучаться до базы, в логах — connection refused или no pg_hba.conf entry: PostgreSQL не принимает подключения. Это классическая проблема, и она почти всегда сводится к трём вещам: на каком адресе слушает сервер, кому разрешён доступ в правилах и открыт ли порт. Разберём по порядку, как найти конкретный барьер и пропустить нужные подключения, не открывая базу всему интернету.

Первое действие: определите характер ошибки

Текст ошибки сразу сужает поиск, поэтому начните с него. Разные сообщения означают разные проблемы:

psql -h 127.0.0.1 -U myuser -d mydb

Если ошибка Connection refused — сервер вообще не слушает на этом адресе или порт закрыт: проблема сетевая (listen_addresses или файрвол). Если no pg_hba.conf entry for host ... — сервер доступен, но правила доступа не разрешают это подключение: проблема в pg_hba.conf. Если password authentication failed — сеть и правила в порядке, дело в пароле или методе аутентификации. Если too many clients already — исчерпан лимит соединений. Сначала точно определите, какое из сообщений вы видите: это сразу указывает, в каком из разделов ниже ваше решение, и избавляет от бесполезных правок не в том месте.

Причина 1: listen_addresses только localhost

По умолчанию PostgreSQL часто слушает только локальный интерфейс, и удалённые подключения к нему невозможны — отсюда Connection refused при попытке подключиться по внешнему адресу. Проверьте параметр listen_addresses в postgresql.conf:

grep listen_addresses /etc/postgresql/*/main/postgresql.conf

Если стоит localhost, сервер принимает только локальные соединения. Чтобы разрешить подключения по нужному интерфейсу, задайте конкретный адрес или, если это оправдано, * (слушать все интерфейсы):

listen_addresses = '*'

После правки нужен перезапуск PostgreSQL, а не просто reload, — этот параметр читается при старте. Важно: открытие listen_addresses = '*' само по себе не пускает всех подряд — доступ всё равно ограничивают правила pg_hba.conf и файрвол. Но без корректного listen_addresses удалённое подключение невозможно в принципе, поэтому это первый шаг для доступа извне.

Причина 2: нет правила в pg_hba.conf

Даже когда сервер слушает нужный интерфейс, каждое подключение проверяется по файлу правил pg_hba.conf. Ошибка no pg_hba.conf entry for host означает, что для вашего адреса, пользователя или базы нет разрешающей строки. Нужно добавить правило, разрешающее подключение с конкретного адреса или подсети с шифрованием и паролем:

host    mydb    myuser    10.0.0.0/24    scram-sha-256

Здесь указаны база, пользователь, разрешённая подсеть и метод аутентификации. Прописывайте максимально узкий диапазон адресов — только те, откуда реально подключается ваше приложение, а не 0.0.0.0/0. После правки pg_hba.conf достаточно перечитать конфигурацию (reload), перезапуск не нужен. Это ключевой файл безопасности PostgreSQL: он определяет, кому и как разрешено подключаться. Не открывайте доступ всему интернету «чтобы заработало» — это прямая дорога к взлому базы.

Причина 3: порт закрыт файрволом

Если сервер слушает нужный интерфейс и правило в pg_hba.conf есть, но снаружи по-прежнему Connection refused или таймаут — порт 5432 закрыт файрволом. Проверьте, слушает ли PostgreSQL и открыт ли порт:

ss -tlnp | grep 5432

Если процесс слушает нужный адрес, но извне недоступен, откройте порт — но строго для доверенного источника, а не для всех:

ufw allow from 10.0.0.5 to any port 5432 proto tcp

Открывать 5432 всему интернету (ufw allow 5432) — плохая идея: базу тут же начнут перебирать боты. Разрешайте доступ только с адресов вашего приложения. Учтите и облачный файрвол провайдера, если он есть: его настраивают отдельно от ufw. Идеальный вариант для удалённого доступа к базе — вообще не выставлять её в интернет, а ходить через приватную сеть между серверами или через SSH-туннель. Тогда порт остаётся закрытым снаружи, а безопасность на порядок выше.

Причина 4: исчерпан лимит соединений

Ошибка FATAL: sorry, too many clients already означает, что достигнут лимит max_connections, и новые подключения отклоняются. Посмотрите текущее число и лимит:

SELECT count(*) FROM pg_stat_activity;
SHOW max_connections;

Если число близко к лимиту, а большинство соединений висят в состоянии idle — приложение не закрывает подключения или не использует пул. PostgreSQL особенно чувствителен к числу соединений: каждое — это отдельный процесс, и тысячи подключений его убивают. Правильное решение почти всегда — поставить пулер соединений (PgBouncer) между приложением и базой, а не бесконечно поднимать max_connections. Пулер держит небольшое число реальных подключений к базе и мультиплексирует через них запросы приложения. Это стандартная практика для PostgreSQL под нагрузкой.

Как проверить, что доступ настроен правильно

После правок проверьте подключение именно так, как ходит приложение — с того же адреса, тем же пользователем и базой. Сначала локально, потом удалённо:

psql "host=ВАШ_АДРЕС port=5432 dbname=mydb user=myuser"

Успешный вход подтверждает, что цепочка «listen_addresses → pg_hba.conf → файрвол → аутентификация» настроена верно. Если на каком-то шаге снова ошибка — её текст точно скажет, где барьер, и вы вернётесь к соответствующему разделу. Полезно держать в голове эту последовательность: PostgreSQL пропускает подключение, только когда пройдены все четыре уровня. Проверяя их по порядку, вы находите проблему за минуты, а не гадаете вслепую.

Профилактика: стабильный и безопасный доступ

Чтобы доступ к базе был и надёжным, и безопасным, настройте его осознанно с самого начала. Не выставляйте PostgreSQL в открытый интернет: держите базу в приватной сети с приложением или ходите через SSH-туннель, а listen_addresses и pg_hba.conf ограничивайте узким кругом доверенных адресов. Используйте современный метод аутентификации scram-sha-256 и надёжные пароли. Для нагруженных приложений сразу закладывайте PgBouncer — он снимает проблему числа соединений на корню.

Документируйте свои правила pg_hba.conf, чтобы через полгода понимать, кому и зачем открыт доступ. Мониторьте число активных соединений — рост idle-подключений заранее предупреждает об утечке в приложении. Такой подход избавляет и от внезапных отказов в подключении, и от риска, что базу найдут и переберут боты. Безопасный доступ к базе — это не разовая настройка «лишь бы заработало», а продуманная схема, которая экономит нервы и защищает данные.

Частые вопросы