Исправление ошибок Nginx 'Connection Refused': Практическое руководство по устранению неполадок

Столкновение с ошибкой 'Connection Refused' при попытке доступа к службе, работающей за Nginx, является распространенным, но раздражающим опытом. В отличие от ошибки 'Timeout', которая указывает на задержку сети или потерю пакетов, ошибка 'Connection Refused' является окончательной: операционная система немедленно отклонила попытку соединения, потому что ни одно приложение не прослушивало указанный порт и IP-адрес.

Это немедленное отклонение указывает на несколько критических областей: служба не работает, брандмауэр блокирует трафик локально или конфигурация направляет трафик на несуществующий порт. Это руководство предлагает систематический четырехфазный подход к диагностике и устранению ошибок 'Connection Refused', гарантируя быстрое восстановление подключения к службе.

Фаза 1: Проверка статуса сервера Nginx (Основной прослушиватель)

Наиболее базовая причина отказа в соединении заключается в том, что сама служба Nginx не работает или настроена неправильно.

1. Проверка статуса службы Nginx

Используйте менеджер служб вашей системы (обычно systemd), чтобы подтвердить, что Nginx активен и работает. Сбой здесь является прямой причиной отказа на основном порту прослушивания (обычно 80 или 443).

sudo systemctl status nginx

Ожидаемый вывод (Успех): Ищите Active: active (running).

Действие по исправлению: Если статус показывает inactive или failed, попробуйте запустить службу и проверьте журналы на наличие деталей сбоя.

sudo systemctl start nginx
sudo journalctl -xe | grep nginx

2. Подтверждение активных прослушиваемых портов

Используйте инструмент ss (статистика сокетов) или netstat, чтобы убедиться, что Nginx действительно привязывается к ожидаемому IP-адресу и порту (например, 0.0.0.0:80 или 127.0.0.1:8080).

# Использование ss (предпочтительно на современных дистрибутивах Linux)
sudo ss -tuln | grep 80

# Использование netstat
sudo netstat -tuln | grep 80

Если вы не видите ожидаемый порт (например, :80 или :443) в списке под процессом (PID), связанным с Nginx, это означает, что Nginx не смог привязаться, вероятно, из-за ошибки конфигурации или другой службы, уже занимающей этот порт.

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

Фаза 2: Брандмауэр и сетевая конфигурация

Если Nginx работает и прослушивает локально, отказ в соединении может происходить вне службы, обычно из-за правил брандмауэра, блокирующих входящий трафик.

1. Проверка локальных брандмауэров сервера

Убедитесь, что порты, которые прослушивает Nginx (например, 80, 443), явно разрешены через брандмауэр хоста (UFW, firewalld или iptables).

Пример UFW (Ubuntu/Debian)

sudo ufw status verbose
# Если закрыто, разрешите порты:
sudo ufw allow 'Nginx Full'
# Или конкретно:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Пример Firewalld (CentOS/RHEL)

sudo firewall-cmd --list-all
# Если закрыто, добавьте службы:
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

2. Проверка групп безопасности облачного провайдера

Если ваш сервер размещен в облачной среде (AWS EC2, Azure VM, GCP Compute Engine), отказ в соединении может исходить от уровня безопасности виртуальной сети.

Группы безопасности AWS (SG): Проверьте связанную SG и убедитесь, что правила входящего трафика разрешают трафик на порты 80 и 443 с исходных IP-адресов (обычно 0.0.0.0/0 для публичного доступа).
Группы сетевой безопасности Azure (NSG): Проверьте правила входящих портов.

Фаза 3: Проверка конфигурации Nginx

Неправильные директивы конфигурации могут привести к тому, что Nginx попытается прослушивать недоступный порт или IP, что приведет к сбою запуска и последующему отказу в соединении.

1. Просмотр директив `listen`

Проверьте ваш основной файл конфигурации (часто /etc/nginx/nginx.conf) и любые соответствующие блоки сервера (обычно в /etc/nginx/conf.d/ или /etc/nginx/sites-enabled/). Убедитесь, что директивы listen корректны.

Пример правильно настроенного блока listen:

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    # ... другие директивы
}

Если Nginx настроен на прослушивание только 127.0.0.1 (localhost), но вы пытаетесь получить к нему доступ через публичный IP, соединение будет отклонено.

2. Запуск проверки синтаксиса конфигурации

Перед перезапуском Nginx всегда проверяйте синтаксис конфигурации. Ошибка парсинга предотвратит запуск службы, вызывая отказ.

sudo nginx -t

Если тест не пройден, исправьте обнаруженную ошибку, повторно запустите тест, а затем перезагрузите или перезапустите Nginx.

sudo systemctl reload nginx

Фаза 4: Устранение неполадок обратного прокси (вышестоящего сервера)

Если Nginx успешно работает на портах 80/443, но доступ к определенному пути (/api/) приводит к 'Connection Refused', проблема находится между Nginx и внутренней службой (вышестоящим сервером).

В этом сценарии Nginx принял начальное соединение, но когда он попытался проксировать запрос, соединение с внутренней службой было отклонено. Журналы ошибок подтвердят это.

1. Проверка журналов ошибок Nginx

Проверьте журналы ошибок Nginx (обычно /var/log/nginx/error.log) сразу после попытки неудачного соединения. Ищите сообщения, связанные с директивой proxy_pass, особенно упоминающие ошибки соединения.

tail -f /var/log/nginx/error.log

Вы можете увидеть запись, подобную:

[error] connect() failed (111: Connection refused) while connecting to upstream

2. Проверка статуса внутренней службы

Это наиболее распространенное исправление в сценариях прокси: внутреннее приложение (например, Node.js, Python Gunicorn, Apache) не работает или не прослушивает там, где ожидает Nginx.

Действия по исправлению:

a. Проверка статуса внутренней службы: Подтвердите, что внутреннее приложение работает.

b. Проверка порта прослушивания внутренней службы: Используйте ss -tuln на сервере, где размещена внутренняя служба, чтобы подтвердить, что приложение прослушивает IP/порт, указанный в директиве proxy_pass Nginx.

3. Прямое тестирование подключения к внутренней службе

Проверьте соединение от сервера Nginx к внутренней службе с помощью curl или telnet, чтобы изолировать проблему от Nginx.

Предположим, ваш proxy_pass установлен на http://127.0.0.1:8080:

# Проверка соединения от сервера Nginx к порту внутренней службы
curl -v http://127.0.0.1:8080

# Или с помощью telnet
telnet 127.0.0.1 8080

Если curl или telnet не работают: Проблема определенно во внутренней службе (она не прослушивает или ее внутренний брандмауэр блокирует доступ к 127.0.0.1).
Если curl или telnet работают: Проблема может быть в тонкой ошибке в вашей директиве proxy_pass (например, отсутствующая точка с запятой, неправильное разрешение имени хоста или несоответствие протокола — HTTP против HTTPS).

Распространенная ошибка `proxy_pass`

Убедитесь, что IP-адрес в вашем proxy_pass соответствует тому, к чему привязана внутренняя служба. Если внутренняя служба привязывается к конкретному IP (например, 192.168.1.10:8080), но Nginx использует localhost:8080, соединение не удастся, если привязка ограничительна.

Финальные проверки ключевых шагов устранения неполадок

Проверка системы: Работает ли Nginx (systemctl status nginx)?
Проверка порта: Прослушивает ли Nginx правильный IP/порт (ss -tuln)?
Проверка брандмауэра: Открыт ли входящий порт на брандмауэре хоста (UFW, iptables)?
Проверка конфигурации: Проходит ли nginx -t и корректны ли директивы listen?
Проверка прокси (если применимо): Работает ли вышестоящая служба и прослушивает ли она точный IP/порт, определенный в proxy_pass? Проверьте подключение напрямую с помощью curl.

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