#Что означает проблема и кому подходит инструкция
В Ubuntu systemctl status показывает active (running), но страница или API приложения не отвечает. Это не противоречие: systemd знает о процессе, однако не гарантирует готовность сетевого порта, правильную маршрутизацию и работоспособность бизнес-функции.
#Возможные причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Процесс не слушает нужный адрес/портПриложение запущено, но слушает только 127.0.0.1 или другой порт. | ss не показывает ожидаемую пару адрес:порт. | Проверить конфигурацию прослушивания. |
| Приложение зависло или не прошло проверку готовностиПроцесс жив, но не отвечает на запросы или ждёт базу данных. | Тайм-аут curl при живом PID, журнал зависимостей содержит ошибки. | Проверить логи и реальные зависимости, не делать бесконечные рестарты. |
| Отвечает локально, но не снаружиМаршрут, firewall или обратный прокси не пропускают запрос. | localhost работает, удалённый клиент — нет. | Диагностировать сеть и промежуточный сервис. |
#Диагностика и пошаговое устранение
- 1. Установите ожидаемую точку доступаОткройте Терминал Ubuntu на сервере. Запишите точный URL, порт и имя службы из конфигурации приложения; не предполагайте стандартный 80 или 443. Через
systemctl showпроверьте PID и состояние. Типы Type=simple и notify по-разному сообщают о готовности; active не означает успешный HTTP.Linux · Терминал (Bash)КомандаПодставьте действительное имя, не выводите конфиденциальное окружение.systemctl status ИМЯ.service --no-pagersystemctl show ИМЯ.service -p MainPID -p Type -p ExecStart
- 2. Проверьте, существует ли слушающий портС помощью
ss -ltnpнайдите нужный TCP-порт и адрес. Если процесс слушает только 127.0.0.1, внешние клиенты не смогут подключиться прямо к нему; это нормально при обратном прокси. Для UNIX-сокетов используйтеss -xlpnи проверьте его права. - Администратор позволяет увидеть владеющий процесс; не изменяет сетьLinux · Терминал (Bash)КомандаНужен sudoАдминистратор позволяет увидеть владеющий процесс; не изменяет сеть.
sudo ss -ltnpsudo ss -xlpn
- 3. Отправьте безопасный локальный запросЕсли приложение HTTP, выполните
curl -v --max-time 10 http://127.0.0.1:ПОРТ/ПУТЬ, подставив порт и безопасный диагностический путь (например, документированную /health, если она существует). Не считайте 404 признаком ошибки сервиса целиком: запрошенный путь может не существовать. Для HTTPS используйте https и проверку сертификата; не добавляйте -k как постоянное решение.Linux · Терминал (Bash)КомандаТолько безопасный GET; не вызывайте адреса, изменяющие данные. Заполнители заменить.curl -v --max-time 10 http://127.0.0.1:ПОРТ/ПУТЬ
- 4. Прочитайте последние ошибки приложения и зависимостей
journalctl -uпоможет найти ошибку базы, файлов, параметров запуска, исчерпания соединений или памяти. Сопоставьте timestamp со своим пробным запросом. Для приложения с отдельными log-файлами читайте только конкретный лог, не публикуя личные данные.Linux · Терминал (Bash)КомандаТолько чтение, в журналах могут быть токены.journalctl -u ИМЯ.service -b --no-pager -n 120systemctl --failed --no-pager
- 5. Сравните локальный и внешний путь запросаЕсли локально ответ есть, но с другого устройства нет, проверьте DNS, адрес прослушивания, маршрут и настройки обратного прокси.
sudo ufw status verboseпоказывает локальные правила при установленном UFW, но в облаках может быть ещё отдельный firewall. Не отключайте защиту целиком ради проверки. - Дополнительная команда по темеLinux · Терминал (Bash)КомандаНужен sudoufw может отсутствовать: тогда проверьте используемые nftables/iptables и правила провайдера.
ip -br addrsudo ufw status verbose
- 6. Изменяйте только доказанную причину и перепроверьтеПосле исправления конфигурации приложения или прокси выполните его штатную проверку синтаксиса, затем согласованный перезапуск. Сверьте status, порт и ответ настоящего клиента. Если приложение отдаёт ответ 200 с ошибкой внутри JSON, проверяйте смысл ответа и журналы, а не только код HTTP.
- Команды проверки; не перезапускать производственный сервис без согласованияLinux · Терминал (Bash)КомандаНужен sudoКоманды проверки; не перезапускать производственный сервис без согласования.
systemctl status ИМЯ.service --no-pagersudo ss -ltnp
#Как убедиться, что неисправность устранена
Работа завершена, когда через нужный маршрут, домен и порт сервис действительно выполняет целевую функцию, а не только остаётся активным процессом.
#Если результат не получен
Не повторяйте опасные действия наугад. Сохраните точную формулировку ошибки, вывод диагностики без секретов, версию Ubuntu и данные о затронутом компоненте. Верните лишь собственные изменения из резервной копии; если затронута загрузка, диски или рабочий сервер, воспользуйтесь консолью восстановления либо помощью администратора.