Redis: отказ в подключении — причины и решение

MAATRIX

Приложение не может достучаться до базы: Connection refused, NOAUTH Authentication required или Connection reset. Redis отказ в подключении — проблема с понятным набором причин: сервис не слушает нужный адрес, включён protected-mode, нужен пароль, мешает фаервол или упёрлись в лимит клиентов. Разберём каждую по симптому и починим доступ, не открыв при этом базу всему интернету.

Сначала определяем тип отказа

Точный текст ошибки сразу сужает поиск — не игнорируйте его. Connection refused означает, что до порта дошли, но никто не слушает или соединение активно отвергнуто. Connection timed out — пакеты не дошли вовсе, почти всегда фаервол или неверный адрес. NOAUTH Authentication required — сервер жив и слышит вас, но требует пароль. DENIED Redis is running in protected mode — включена защита от внешних подключений. ERR max number of clients reached — исчерпан лимит соединений.

Каждая формулировка ведёт к своему разделу ниже. Первым делом проверьте, отвечает ли Redis локально — это разделяет проблемы «сервис не работает» и «сервис работает, но недоступен снаружи».

redis-cli ping
redis-cli -h 127.0.0.1 -p 6379 ping

Ответ PONG локально означает, что Redis жив, и проблема в доступе снаружи (bind, protected-mode, фаервол). Ошибка даже локально — сервис не запущен или слушает не тот порт. Это первая развилка, от неё и пляшем.

Такое разделение экономит массу времени. Очень часто отладку ведут не с той стороны: правят конфиг приложения, перебирают строки подключения и пароли, хотя Redis на сервере вовсе не запущен, — или наоборот, перезапускают сервис, который и так работает, тогда как реальная преграда стоит на уровне фаервола между машинами. Один локальный ping сразу говорит, на чьей стороне искать: если база отвечает сама себе, значит, дело в сетевом пути к ней, а не в самом Redis. Начинайте всегда с этой проверки, а не с догадок.

Сервис не запущен или слушает не там

Если локальный ping не отвечает, проверьте, работает ли процесс и на каком адресе с портом он слушает.

systemctl status redis-server
ss -tlnp | grep 6379
journalctl -u redis-server -n 30

Если процесса нет — запустите его (systemctl start redis-server) и посмотрите в лог, почему он падал: часто это ошибка конфига, занятый порт или нехватка памяти при загрузке снимка. Если процесс есть, но ss показывает, что он слушает не 6379, а другой порт, или только 127.0.0.1 вместо нужного адреса — дело в конфиге. Порт задаётся директивой port, а адрес — bind. Свежий взгляд на вывод ss часто решает проблему за секунды: клиент стучится на один адрес и порт, а Redis слушает другие.

Redis слушает только localhost (bind)

Самая частая причина недоступности снаружи: по умолчанию Redis привязан к 127.0.0.1 и принимает подключения только с той же машины. Приложение с другого сервера получает Connection refused или таймаут. Директива bind определяет, на каких интерфейсах слушать.

bind 127.0.0.1 10.0.0.5
protected-mode yes
port 6379

Здесь важен баланс безопасности. Не пишите bind 0.0.0.0 без пароля и фаервола — это открывает базу всему интернету, и её найдут и вычистят автоматические сканеры за часы. Правильно — привязать Redis к внутреннему адресу (приватная сеть между вашими серверами) и оставить protected-mode yes. Если приложение и Redis на разных серверах, свяжите их через приватную сеть провайдера и укажите в bind именно внутренний интерфейс, а не публичный. После правки перезапустите Redis.

Protected-mode и пароль

Начиная с версии 3.2, Redis по умолчанию включает protected-mode: если он слушает на внешнем интерфейсе, но пароль не задан, внешние подключения отклоняются с DENIED Redis is running in protected mode. Это защита от случайного открытия базы наружу. Правильное решение — не отключать защиту, а задать пароль.

requirepass ВашСложныйПарольЗдесь

Теперь клиенты обязаны авторизоваться, иначе получат NOAUTH Authentication required. Подключение с паролем:

redis-cli -h 10.0.0.5 -p 6379 -a 'ВашСложныйПароль' ping
# или после подключения:
redis-cli -h 10.0.0.5
127.0.0.1:6379> AUTH ВашСложныйПароль

Никогда не выключайте protected-mode ради быстрого доступа, оставив базу без пароля на внешнем интерфейсе — это прямой путь к взлому и шифровальщику. Пароль плюс привязка к приватной сети плюс фаервол — вот безопасная комбинация. В приложении пропишите пароль в строке подключения, и NOAUTH исчезнет.

Фаервол блокирует порт

Если локально всё работает, Redis слушает нужный адрес, пароль задан, а снаружи по-прежнему таймаут — почти наверняка порт закрыт фаерволом. Redis по умолчанию на 6379, и его нужно открыть только для доверенных адресов, но не для всего мира.

ss -tlnp | grep 6379          # локально слушает?
ufw status | grep 6379
# проверить доступность порта с клиентской машины:
nc -vz 10.0.0.5 6379

Откройте порт прицельно, только с адреса вашего приложения — это критично для безопасности:

ufw allow from 10.0.0.6 to any port 6379 proto tcp

Так к Redis сможет подключиться только конкретный сервер приложения, а не любой желающий. Никогда не открывайте 6379 командой ufw allow 6379 без ограничения источника — открытый в интернет Redis сканируют и захватывают моментально. Если провайдер даёт облачный firewall/security group, дублируйте правило и там. Таймаут при закрытом порте — это хорошо: значит, защита работает, надо лишь пустить своих.

Исчерпан лимит клиентов

Ошибка ERR max number of clients reached означает, что все слоты подключений заняты. Причина — либо реально высокая нагрузка, либо утечка соединений в приложении, которое открывает подключения и не закрывает. Проверьте текущее и максимальное число клиентов.

redis-cli INFO clients
redis-cli CONFIG GET maxclients
redis-cli CLIENT LIST | wc -l

Если число клиентов близко к maxclients и растёт — ищите утечку в приложении: почти всегда виноват отсутствующий пул соединений или незакрытые коннекты. Поднять лимит можно, но это лечение симптома:

redis-cli CONFIG SET maxclients 10000

Правильнее — настроить в приложении пул соединений с разумным размером, чтобы оно переиспользовало коннекты, а не плодило новые на каждый запрос. Также проверьте системный лимит файловых дескрипторов (ulimit -n): Redis не сможет держать больше клиентов, чем разрешено дескрипторов процессу. Устраните утечку — и лимит перестанет упираться.

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