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

Столкнуться с ошибкой '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: Устранение неполадок обратного прокси (Upstream)

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

В этом сценарии 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/порт, указанный в директиве Nginx proxy_pass.

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, соединение завершится неудачей, если привязка является ограничительной.

---

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

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

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