Чтобы проверить доступность сервера, идут по четырём слоям: отвечает ли адрес на ping, открыт ли нужный порт, отдаёт ли приложение HTTP-код и превращается ли домен в правильный IP-адрес. Каждый слой проверяется одной командой и занимает секунды, а неудача на конкретном шаге сразу сужает круг причин. Такой порядок работает одинаково и на домашнем компьютере, и на арендованном сервере с Linux — меняются только адреса и номера портов.
Материал для владельца сайта и начинающего администратора, у которого проект перестал открываться. Разберём четыре команды диагностики снаружи и четыре команды изнутри сервера. Затем — что означает каждый неудачный ответ и как отличить падение машины от поломки на своей стороне. В конце — порядок проверки за пять минут и настройка постоянного контроля.
Что означает «сервер недоступен»: четыре разных поломки
Фраза «сервер лежит» описывает результат, а не причину. За ней прячутся минимум четыре независимые поломки, и лечатся они по-разному. Машина может быть выключена целиком, может работать, но не пускать по нужному порту, может пускать, но отдавать ошибку приложения, а может быть жива и здорова — просто домен перестал указывать на её адрес.
Отсюда правило диагностики: не пытаться угадать причину, а проверять слои по очереди от самого нижнего. Нижний слой — сеть и сам факт, что железо отвечает. Верхний — конкретное приложение вроде веб-сервера или базы данных.
Порядок важен, потому что верхние слои зависят от нижних. Если машина выключена, бессмысленно смотреть логи nginx. Если домен указывает на чужой адрес, диагностика на своём сервере покажет идеальную картину, а сайт всё равно не откроется.
Каждый слой даёт ответ «да» или «нет»: проверка прошла или не прошла. Четыре ответа складываются в диагноз за две-три минуты, без гадания и без обращения в поддержку с формулировкой «у меня ничего не работает».
Первое действие: понять, у всех лежит или только у вас
Прежде чем разбирать сервер, отбросьте вариант, что проблема на вашей стороне. Домашний роутер, кэш браузера или локальный DNS ломают доступ к рабочему сайту не реже, чем настоящие аварии в дата-центре.
Быстрый способ: откройте сайт с мобильного интернета, отключив Wi-Fi. Если с телефона открывается, а с компьютера нет — сервер жив, чините сеть у себя. Если не открывается нигде, переходите к проверке слоёв.
Второй маркер — время появления проблемы. Сайт перестал открываться сразу после ваших правок конфигурации или обновления пакетов? Тогда причина почти наверняка в этих правках, а не в аварии провайдера. Дата-центры падают редко, а ошибки в конфигах случаются каждый день.
Третий маркер — доступность соседних сервисов. Если на том же сервере живут сайт и почта, и почта работает, значит машина и сеть в порядке, а сломался конкретно веб-сервер. Это сразу переводит диагностику на верхний слой.
Слой сети: ping и почему тишина не равно падению
Ping — команда, которая отправляет на адрес маленький служебный пакет и ждёт ответа. Пакет идёт по протоколу ICMP, отдельному от веба и почты. Ответ приходит с указанием задержки в миллисекундах.
ping -c 4 example.comФлаг -c 4 ограничивает проверку четырьмя пакетами, иначе команда будет работать бесконечно. Успешный ответ выглядит как четыре строки со временем: для сервера в Москве это обычно 5–30 мс, для Европы 40–70 мс, для США 120–200 мс. Строка про потери пакетов в конце должна показывать 0%.
Главная ловушка: молчание ping не доказывает, что сервер упал. Многие провайдеры и хостинги режут ICMP на границе сети — это стандартная мера против сканирования и мусорного трафика. Сервер при этом прекрасно отдаёт сайт, но на ping не отвечает никогда, ни в аварии, ни в норме.
Поэтому ping полезен как подтверждение, а не как приговор. Ответ есть — сеть и машина точно живы, идём выше. Ответа нет — вывод пока не делаем, проверяем порт.
Слой порта: nc и telnet проверяют, слушает ли служба
Порт — номер, по которому на одной машине различаются разные службы. Сайт по HTTPS слушает порт 443/TCP, обычный HTTP — 80/TCP, вход по SSH — 22/TCP, MySQL — 3306/TCP, PostgreSQL — 5432/TCP. Проверка порта отвечает на вопрос: принимает ли конкретная служба соединения снаружи.
nc -zv example.com 443
telnet example.com 443Утилита nc (сокращение от netcat) с флагами -z (только проверить, ничего не передавать) и -v (подробный вывод) печатает «succeeded» при открытом порте. Команда telnet делает то же самое: пустой экран с курсором означает, что соединение установлено, а мгновенное «Connection refused» — что порт закрыт.
Два варианта отказа различаются по поведению и означают разное. «Connection refused» приходит мгновенно: машина жива и ответила, но на этом порту никто не слушает — служба остановлена. Зависание на 10–30 секунд с итоговым таймаутом означает, что пакет вообще не дошёл: файрвол молча его отбросил или машина выключена.
Эта пара ответов — самый информативный шаг всей диагностики. Быстрый отказ переводит вас на сервер поднимать службу, долгий таймаут — разбираться с правилами доступа файрвола. Проверять порт всегда стоит по IP-адресу, а не по домену: так из уравнения уходит ещё и DNS.
Слой приложения: curl -I и чтение кода ответа
Открытый порт ещё не значит рабочий сайт. Веб-сервер может принимать соединения и при этом отдавать ошибку на каждый запрос. Проверить это позволяет curl — консольный клиент, который делает такой же запрос, как браузер, но показывает голый ответ.
curl -I https://example.comФлаг -I запрашивает только заголовки, без тела страницы: ответ умещается в 10–15 строк. Первая строка содержит код: 200 — страница отдана, 301 и 302 — переадресация, 403 — доступ запрещён, 404 — адреса нет, 500 и 502 — ошибка на стороне сервера.
Код 200 при неоткрывающемся сайте означает, что сервер в порядке, а проблема в браузере, кэше или скриптах страницы. Код 502 говорит, что веб-сервер жив, но приложение за ним не отвечает: упал PHP-FPM (служба, которая выполняет PHP-код) или процесс Node.js. Расшифровка остальных вариантов собрана в справочнике по кодам ошибок HTTP.
Если curl обрывается с ошибкой сертификата, сайт работает, но у него истёк SSL-сертификат. Это отдельная поломка, которую браузер показывает как «сайт недоступен». Проверять её нужно по дате в сообщении, а не по коду ответа.
Слой домена: dig и проверка DNS
DNS переводит имя сайта в IP-адрес. Пока перевод сломан, сервер может быть идеально исправен — браузер просто не знает, куда стучаться. Отдельная проверка нужна после любого переезда, смены хостинга или правки записей у регистратора.
dig example.com A +shortКоманда запрашивает A-запись — тот самый IP-адрес — и с ключом +short печатает только результат, одну строку. Сравните её с реальным адресом вашего сервера: расхождение и есть причина.
Пустой ответ означает, что запись не существует или ещё не разошлась по сети. Обновления DNS распространяются по миру за время TTL — это срок, который чужие серверы хранят старый ответ в кэше, обычно от 300 секунд до 24 часов, поэтому после переезда сайт часть суток открывается через раз: у кого-то кэш уже обновился, у кого-то нет.
Если dig вообще не отвечает, проблема в DNS-сервере, а не в вашей записи. Разбор типовых случаев есть в материале о том, как проверить DNS.
Где теряются пакеты: traceroute и mtr
Когда ping не проходит, а порт даёт таймаут, остаётся вопрос: обрыв на вашей стороне, у промежуточного оператора или у хостинга. Ответ даёт traceroute — команда показывает всю цепочку узлов между вами и сервером.
traceroute example.com
mtr example.comКаждая строка вывода — один маршрутизатор на пути, обычно их 8–20. Звёздочки вместо времени означают, что узел не ответил. Одна-две звёздочки в середине маршрута нормальны: транзитные роутеры часто не отвечают на служебные пакеты. Тревожный признак — звёздочки со среднего узла и до самого конца.
Утилита mtr делает то же самое непрерывно и сводит статистику в таблицу с процентом потерь по каждому узлу. Потери 1–2% на транзитном узле безобидны, потери 30% и выше на последних узлах — реальная проблема сети хостинга.
| Слой | Команда | Признак нормы | Что означает отказ |
|---|---|---|---|
| Сеть | ping -c 4 | 4 ответа, потери 0% | Машина выключена либо ICMP закрыт |
| Порт | nc -zv host 443 | succeeded | Refused — служба стоит, таймаут — файрвол |
| Приложение | curl -I | Код 200 или 301 | 502 — упало приложение за веб-сервером, 403 — закрыт доступ |
| Домен | dig A +short | Ожидаемый IP | Пусто — записи нет, другой IP — старый кэш |
| Маршрут | mtr | Потери до 2% | Обрыв на конкретном узле сети |
Диагностика изнутри: uptime, systemctl, ss, journalctl
Если по SSH зайти удалось, картина становится точной. Четыре команды закрывают почти все сценарии и выполняются за минуту.
uptime
systemctl status nginx
ss -lntp
journalctl -xeКоманда uptime показывает, сколько машина работает без перезагрузки, и три числа средней нагрузки за 1, 5 и 15 минут. Если во время аварии это время оказалось маленьким — несколько минут, — значит сервер только что перезагрузился сам. Нагрузка выше числа ядер — перегрузка: на 2 ядрах значение 8 говорит о четырёхкратной очереди задач.
Команда systemctl status с именем службы печатает её состояние: active (running) — работает, failed — упала, inactive (dead) — остановлена. Утилита ss -lntp выводит список занятых портов с именами процессов: -l — только слушающие сокеты, -n — номера портов вместо названий, -t — протокол TCP, -p — имя процесса. Если нужного порта в списке нет, служба не слушает и её нужно перезапустить.
Команда journalctl -xe открывает свежие записи системного журнала с расшифровкой. Читать нужно последние 20–30 строк — там лежит текст реальной ошибки: нехватка памяти, конфликт портов, синтаксическая опечатка в конфиге.
Порядок проверки за пять минут
Последовательность ниже подходит для любой аварии и не требует держать в голове теорию. Каждый шаг либо даёт диагноз, либо передаёт эстафету следующему.
- Откройте сайт с мобильного интернета — если работает, чините сеть у себя, диагностика окончена.
- Выполните
dig example.com A +shortи сверьте IP с адресом сервера в панели хостинга. - Выполните
ping -c 4по IP, а не по домену — так исключается влияние DNS. - Проверьте порт:
nc -zv IP 443для сайта иnc -zv IP 22для SSH. - Если порт открыт, запросите
curl -I https://example.comи прочитайте код ответа. - Зайдите по SSH и выполните
uptime,systemctl statusнужной службы иjournalctl -xe. - Если SSH не пускает, а порт 22/TCP даёт таймаут, откройте консоль через панель хостинга.
Консоль в панели управления — последний рубеж: она подключается к машине напрямую, минуя сеть, и работает даже при полностью закрытом файрволе. Ошибка, когда администратор сам себе закрыл доступ правилом файрвола, случается регулярно, и именно эта кнопка спасает от переустановки системы.
Постоянный контроль: мониторинг с интервалом 1–5 минут
Ручная проверка запускается уже после жалобы клиента. Внешний мониторинг узнаёт о падении раньше: сервис с чужой площадки стучится на ваш адрес по расписанию и шлёт уведомление, если ответ не пришёл.
Разумный интервал — от 1 до 5 минут. Минутная проверка ловит короткие сбои, но чаще даёт ложные срабатывания на сетевых заминках. Пятиминутная спокойнее, но авария длиной 3 минуты пройдёт незамеченной. Компромисс для небольшого проекта — 2 минуты и оповещение только после двух неудач подряд.
Проверять стоит не ping, а именно HTTP-ответ с кодом 200 и, при возможности, наличие ключевого слова на странице. Сайт, отдающий 502 на каждый запрос, для ICMP выглядит совершенно живым. Уведомления удобно направлять в мессенджер — так тревога доходит за секунды, а не при следующей проверке почты.
Свой мониторинг можно поднять на той же машине только как дополнение: если сервер упадёт, некому будет прислать письмо. Поэтому основной наблюдатель всегда живёт снаружи. Практическая настройка разобрана в руководстве по мониторингу сервера.
На каком сервере отрабатывать команды
Все перечисленные утилиты входят в стандартную поставку Linux и не требуют ресурсов. Отдельная машина для тренировки и для внешнего наблюдателя обходится дешевле подписки на мониторинг, а заодно даёт вторую точку, с которой видно ваш основной сервер.
Для этой задачи хватает минимальной конфигурации: 1 ядро, 1 ГБ памяти и 5–10 ГБ диска. В каталоге из 44 площадок такие тарифы стоят от 59 ₽/мес — это уровень недорогих VPS, где сервер держится под нагрузкой около нуля.
| Провайдер | Цена от | Базовая конфигурация |
|---|---|---|
| Cloudcore | 59 ₽/мес | 1 ядро, 1 ГБ RAM, 10 ГБ NVMe |
| Hosting-Russia | 99 ₽/мес | Минимальный тариф VPS |
| 4VPS | 110 ₽/мес | 1 ядро, 1 ГБ RAM, 5 ГБ NVMe |
| HostVDS | 127 ₽/мес | 1 ядро, 1 ГБ RAM, 10 ГБ NVMe |
Данные проверены 04.09.2026.
Наблюдателя разумно ставить в другой стране или хотя бы у другого провайдера, чем основной проект. Две машины в одном дата-центре упадут вместе, и тревоги вы не получите. Разница в цене между площадками здесь не принципиальна: 59 и 127 ₽/мес отличаются на 68 ₽, то есть на 816 ₽ за год.
Частые ошибки
Ошибки в диагностике стоят дороже самой аварии: неверный вывод уводит на часы в сторону. Ниже — случаи, которые повторяются чаще всего.
- Считать отсутствие ответа на ping доказательством падения — ICMP закрыт у половины площадок.
- Проверять сайт по домену, когда сломан DNS: тестировать нужно по IP-адресу.
- Смотреть логи приложения, не убедившись, что машина вообще включена.
- Мониторить порт 443/TCP вместо HTTP-кода: порт открыт, а сайт отдаёт 502.
- Забыть про истёкший сертификат — браузер показывает это как недоступность.
- Держать мониторинг на той же машине, за которой он следит.
Отдельный случай — закрытие доступа самому себе неудачным правилом файрвола. Симптом узнаваем: сайт открывается у всех, кроме вас, а SSH даёт таймаут. Лечится через консоль в панели хостинга за две минуты.
Частые вопросы
Сервер не пингуется, но сайт открывается — это нормально? Да, и встречается постоянно. Провайдер закрыл ICMP на границе сети, поэтому ping молчит всегда, независимо от состояния машины. Ориентируйтесь на проверку порта и HTTP-код ответа.
Чем «Connection refused» отличается от таймаута? Отказ приходит мгновенно и означает, что машина ответила, но на этом порту служба не слушает — её нужно запустить. Таймаут длится 10–30 секунд и означает, что пакет не дошёл: сработал файрвол или сервер выключен.
Как проверить доступность сервера без командной строки? Подойдёт любой внешний сервис проверки, который открывает адрес со своих площадок и показывает код ответа. Он заменяет связку ping и curl, но не даёт заглянуть внутрь машины — логи всё равно придётся смотреть по SSH.
Сколько ждать после смены DNS-записей? Ориентируйтесь на TTL записи: обычно от 300 секунд до 24 часов. Всё это время часть посетителей идёт на старый адрес, а часть на новый, поэтому сайт открывается через раз. Понизьте TTL до 300 секунд за сутки до переезда.
Что значит нагрузка 8.00 в выводе uptime? Это средняя очередь задач за последнюю минуту. Сравнивайте её с числом ядер: на 8 ядрах такое значение — полная загрузка без запаса, на 2 ядрах — четырёхкратная перегрузка, при которой сервер отвечает с задержкой в секунды.
Какой интервал мониторинга выбрать? Для сайта небольшой компании достаточно 2–5 минут с оповещением после двух неудачных проверок подряд. Интервал в 1 минуту нужен интернет-магазину и платёжным сервисам, где каждая минута простоя считается деньгами.
Порт открыт, curl отдаёт 502 — куда смотреть? Веб-сервер работает, а приложение за ним не отвечает. Выполните systemctl status для PHP-FPM или процесса приложения и прочитайте последние строки journalctl -xe: там будет причина падения, чаще всего нехватка памяти.
Итог
Проверка доступности сервера — это четыре команды в строгом порядке: dig для домена, ping для сети, nc для порта, curl -I для приложения. Каждая отсекает свой слой, и уже через три минуты вы знаете, чинить конфиг, поднимать службу или писать в поддержку хостинга. Изнутри картину дополняют uptime, systemctl status, ss -lntp и journalctl -xe.
Чтобы не узнавать об авариях от клиентов, повесьте внешний мониторинг с интервалом 2–5 минут и проверкой HTTP-кода, а не только ping. Наблюдателю хватит машины за 59–127 ₽/мес у другого провайдера — сравнить тарифы можно в каталоге VPS и VDS.
