Сервер еще вчера работал нормально, а сегодня к нему невозможно подключиться. Сайт не открывается, SSH не отвечает, панель управления недоступна. В такой ситуации легко решить, что VPS просто упал, и сразу отправиться писать в поддержку хостинга. Но недоступность сервера не всегда означает поломку самого сервера.
Проблема может находиться на разных уровнях. Иногда виртуальная машина действительно остановлена. Иногда она работает, но соединения блокирует firewall. В другом случае сервер доступен, а не работает только веб-сервер или приложение. Бывает и так, что с VPS все в порядке, но домен ведет на неправильный IP или между пользователем и дата-центром возникла сетевая проблема.
Поэтому главное правило при такой аварии простое: сначала определить, что именно перестало отвечать. Это намного полезнее, чем перезагружать сервер и менять настройки наугад.
Что значит сервер не отвечает
Фраза сервер не отвечает слишком расплывчата для диагностики. За ней могут скрываться совершенно разные ситуации.
- не открывается сайт по доменному имени;
- сайт не открывается даже по IP;
- невозможно подключиться по SSH;
- не отвечает RDP на Windows Server;
- панель хостинга показывает, что VPS запущен, но соединения нет;
- сервер отвечает на одни запросы, но не обслуживает сайт;
- недоступен только один сервис;
- соединение работает из одной сети, но не устанавливается из другой.
Все эти случаи выглядят для владельца проекта примерно одинаково: ничего не работает. С технической точки зрения причины у них совершенно разные.
Если браузер показывает страницу с HTTP-ошибкой, соединение с какой-то частью инфраструктуры уже состоялось. Например, 502 и 504 обычно говорят о проблемах внутри цепочки обработки запроса. Если же браузер вообще не может установить соединение, искать причину нужно шире.
Сначала проверьте, действительно ли сервер недоступен
Начать стоит с простого эксперимента. Попробуйте открыть сайт с другого подключения. Например, сначала через домашний интернет, затем со смартфона через мобильную сеть.
Если сервер не отвечает только из одной сети, это уже важная подсказка. Сам VPS может продолжать работать. Проблема способна находиться в маршрутизации, блокировке конкретного IP, настройках защиты или сети интернет-провайдера.
Если недоступность наблюдается из нескольких независимых сетей, вероятность проблемы на стороне сервера или дата-центра становится выше.
Еще полезнее внешний мониторинг, если он был настроен заранее. История проверок покажет точное время начала сбоя и поможет понять, был ли это короткий единичный инцидент или сервер остается недоступным постоянно.
Проверьте состояние VPS в панели хостинга
Если речь идет о VPS, откройте личный кабинет провайдера и посмотрите состояние виртуальной машины. Обычно там можно увидеть, запущен сервер, остановлен или находится в процессе перезагрузки.
Остановленная виртуальная машина объясняет проблему сразу. Но статус запущен еще не означает, что внутри все работает нормально.
Гипервизор может видеть работающую виртуальную машину, тогда как операционная система зависла, закончилась память или перестали отвечать сетевые службы. Поэтому зеленого индикатора в панели недостаточно.
У некоторых провайдеров доступна консоль сервера через браузер. Она особенно полезна в ситуации, когда SSH или RDP не работают. Консоль подключается к виртуальной машине другим способом и позволяет увидеть ее состояние даже при неисправной сетевой конфигурации.
Если через консоль система работает, но подключиться к ней по сети невозможно, круг поиска заметно сужается.
Домен и сервер нужно проверять отдельно
Одна из распространенных ошибок состоит в том, что владелец проверяет только доменное имя. Сайт не открывается, значит сервер упал. На самом деле между доменом и VPS находится DNS.
Предположим, сервер имеет новый IP после переноса, а A-запись домена осталась старой. Пользователь обращается не к тому серверу и получает ошибку, хотя новый VPS прекрасно работает.
Похожая ситуация возможна при неправильной AAAA-записи. Часть устройств может пытаться подключаться по IPv6, тогда как соответствующий адрес настроен неверно.
Поэтому при аварии важно выяснить, на какой IP сейчас указывает домен, и сравнить его с фактическим адресом VPS в панели провайдера.
Если IP не совпадает, сначала разбирайтесь с DNS. Если совпадает, идем дальше.
Если SSH не отвечает, это еще не означает падение VPS
SSH часто становится главным способом проверки Linux-сервера. Если подключение не устанавливается, возникает ощущение, что машина полностью недоступна. Но SSH является всего лишь одной службой.
Причиной могут оказаться остановленный SSH-сервис, измененный порт, правило firewall, блокировка вашего IP или ошибка конфигурации после редактирования настроек.
Особенно подозрительна ситуация, когда доступ исчез сразу после изменения firewall, SSH-конфигурации или сетевых параметров.
В этом случае не стоит начинать с DNS или переустановки сайта. Сначала нужно проверить последнее изменение.
Если провайдер предоставляет веб-консоль, войдите через нее и посмотрите, загрузилась ли операционная система и работает ли нужная служба. Такой доступ способен буквально спасти VPS после неудачной настройки firewall, когда администратор случайно закрыл себе SSH.
Проверьте, отвечает ли сама операционная система
Иногда VPS запущен, но Linux или Windows внутри виртуальной машины зависли. Причиной может стать нехватка ресурсов, сбой ядра, проблема с диском, неудачное обновление или другая системная ошибка.
Через консоль провайдера можно увидеть, дошла ли система до экрана входа, не остановилась ли загрузка на ошибке и реагирует ли сервер на действия пользователя.
Если система отвечает через консоль, а сетевого доступа нет, проблема почти наверняка находится не в полном падении виртуальной машины.
Если же консоль тоже показывает зависшую систему, понадобится уже системная диагностика. Перезагрузка в такой ситуации может вернуть сервер к жизни, но по возможности сначала стоит зафиксировать состояние и посмотреть сообщения об ошибках.
Автоматически перезагружать VPS при любой недоступности не лучшая привычка. После перезагрузки часть следов проблемы исчезает, и повторяющийся сбой становится сложнее расследовать.
Сервер может работать, а веб-сервер нет
Представим другую ситуацию. SSH подключается без проблем, система работает, ресурсы доступны, но сайт не открывается.
Это уже хороший признак: сам VPS, скорее всего, жив. Теперь нужно проверять службы, которые обслуживают сайт.
В зависимости от конфигурации проекта это могут быть Nginx, Apache, PHP-FPM, база данных, контейнеры Docker, приложение на Node.js, Python или другом стеке.
Остановка одного компонента способна сделать сайт недоступным при совершенно исправном сервере.
Например, Nginx может работать, но не иметь возможности передать запрос PHP-FPM. Или веб-сервер доступен, а база данных остановлена. Приложение может аварийно завершиться, тогда как все остальные службы продолжают работать.
Поэтому вопрос сервер работает или нет нужно разделять с вопросом работает ли сайт.
Не закончились ли ресурсы
Очень распространенная причина странного поведения VPS связана с ресурсами. Сервер не обязан полностью выключиться, когда ему становится тесно.
При нехватке оперативной памяти система может начать активно использовать swap, завершать процессы или практически перестать нормально реагировать на нагрузку. При заполненном диске приложения перестают записывать временные файлы и журналы, база данных может столкнуться с ошибками, а отдельные службы откажутся запускаться.
Высокая загрузка процессора тоже способна создать впечатление зависшего сервера. Соединения устанавливаются очень медленно или истекают по таймауту.
Поэтому на доступном через консоль или SSH VPS стоит проверить как минимум:
- использование оперативной памяти;
- загрузку процессора;
- свободное место на диске;
- состояние swap;
- число и состояние процессов;
- системную нагрузку;
- работу основных служб проекта.
Важно не только увидеть высокий показатель, но и понять его причину. Если память съедает один аварийный процесс, увеличение тарифа не обязательно является правильным решением. Если же проект стабильно использует почти все доступные ресурсы при нормальной работе, VPS действительно мог стать ему мал.
Что проверить в firewall
Сетевой экран способен сделать работающий сервер практически невидимым снаружи. Причем firewall может существовать сразу в нескольких местах.
Один уровень работает внутри операционной системы. Другой иногда предоставляет сам хостинг-провайдер в панели управления. Дополнительно правила фильтрации могут действовать в CDN, системе защиты от атак или другой внешней инфраструктуре.
Если сайт или SSH перестали работать сразу после изменения правил, проверку логично начинать именно здесь.
Обратите внимание и на частичную недоступность. Например, веб-сайт открывается, но SSH не работает. Это скорее похоже на проблему конкретного порта или службы, чем на падение всего VPS.
Обратная ситуация тоже показательна: SSH доступен, а соединения к веб-серверу не проходят. Значит, сетевой доступ к машине в целом существует.
Когда виновата сеть
Между вашим компьютером и сервером находится множество сетевых узлов. Неисправность одного участка маршрута способна сделать VPS недоступным для определенных пользователей, хотя сам сервер продолжает работать.
Особенно характерна ситуация, когда сервер доступен из одной сети и совершенно не отвечает из другой.
Здесь полезно сравнивать результаты из нескольких независимых точек. Если проблема существует только у одного оператора связи или в определенном регионе, эта информация очень пригодится технической поддержке.
Не стоит при этом делать вывод о неисправности конкретного маршрутизатора только по одной проверке. Сетевые инструменты дают диагностические признаки, которые нужно рассматривать вместе с другими данными.
Если же сервер одновременно перестал быть доступен из множества независимых сетей, следует проверить сообщения хостинг-провайдера и состояние инфраструктуры дата-центра.
Когда проблема находится у хостинг-провайдера
Не каждый сбой можно исправить внутри VPS. Виртуальная машина зависит от физического узла, сети, хранилища и другой инфраструктуры провайдера.
Если произошла авария физического сервера, проблема с системой хранения данных или сетью дата-центра, пользователь может вообще не иметь технической возможности восстановить доступ самостоятельно.
На массовую проблему указывают несколько признаков. Например, одновременно недоступны несколько ваших VPS у одного провайдера, не работает часть панели управления или хостер уже сообщил об аварийных работах.
В такой ситуации особенно важно не пытаться чинить конфигурацию рабочего сервера только потому, что он недоступен извне. Если причина находится в сети дата-центра, изменение Nginx, DNS или SSH ничего не исправит.
Как отличить проблему сервера от проблемы приложения
Самый полезный подход состоит в последовательном сужении области неисправности.
Если VPS недоступен по сети и не отвечает через консоль, проверяйте состояние виртуальной машины и инфраструктуру провайдера.
Если консоль работает, а сеть нет, проверяйте сетевую конфигурацию, IP, маршрутизацию и firewall.
Если SSH работает, но сайт нет, переходите к веб-серверу, приложению, PHP, контейнерам и базе данных.
Если сайт открывается по IP или при прямом обращении к серверу, но не работает через домен, проверяйте DNS и конфигурацию виртуального хоста.
Если сервер и приложение доступны, но проблемы наблюдаются только у части посетителей, нужно смотреть DNS, IPv4 и IPv6, CDN, защиту и сетевые маршруты.
Такая последовательность намного эффективнее хаотичной проверки десятков настроек.
Почему не стоит сразу перезагружать сервер
Перезагрузка кажется универсальным способом ремонта. И действительно, зависший VPS после нее нередко снова начинает отвечать.
Проблема в том, что причина остается неизвестной.
Допустим, сервер зависает раз в несколько дней из-за утечки памяти в приложении. Перезагрузка освобождает RAM, и сайт снова работает. Через несколько дней история повторяется.
Если каждый раз просто нажимать Restart, можно месяцами лечить симптом вместо неисправности.
Перед перезагрузкой, когда это возможно, полезно посмотреть использование ресурсов, список процессов и системные журналы. Зафиксируйте время начала сбоя. Если сервер отвечает через консоль, сохраните информацию о его состоянии.
После этого перезагрузка уже будет осознанным действием, а не единственным способом диагностики.
Логи часто рассказывают больше страницы с ошибкой
Если доступ к системе сохранился, журналы становятся одним из главных источников информации. В них можно увидеть остановку службы, ошибки диска, проблемы приложения, неудачный запуск после обновления и другие события, совпадающие по времени с началом недоступности.
При этом смотреть только один журнал недостаточно. У веб-сервера, приложения, базы данных и самой операционной системы могут быть разные источники событий.
Особенно полезно сопоставлять время.
Например, внешний мониторинг зафиксировал недоступность в 14:17. В системном журнале в 14:16 появилась проблема с памятью, а сразу после нее завершился процесс приложения. Такая последовательность уже дает направление для расследования.
Именно поэтому точное время сбоя полезнее сообщения сервер вчера вечером вроде не работал.
Что написать в поддержку хостинга
Если самостоятельно найти причину не удалось, качество обращения в поддержку сильно влияет на скорость диагностики.
Сообщение VPS не работает почти бесполезно. Специалисту придется сначала задавать вопросы, которые можно было указать сразу.
Лучше сообщить:
- когда примерно началась проблема;
- какой VPS или IP недоступен;
- не работает весь сервер или только сайт;
- доступен ли SSH или RDP;
- работает ли консоль в панели;
- наблюдается ли проблема из нескольких сетей;
- вносились ли изменения непосредственно перед сбоем;
- помогала ли перезагрузка и повторяется ли проблема после нее.
Если есть сообщения об ошибках или точное время неудачного подключения, их тоже стоит передать. Поддержке будет проще сопоставить ваш инцидент с журналами инфраструктуры.
Когда проблема говорит о неправильно выбранном VPS
Один сбой еще не означает, что нужно менять сервер или хостинг. Любая инфраструктура может столкнуться с отдельным инцидентом.
Настораживать должна повторяемость.
Если VPS регулярно упирается в память, постоянно работает с высокой нагрузкой, диск почти заполнен, а увеличение посещаемости сразу приводит к недоступности, стоит оценить ресурсы проекта. Возможно, текущая конфигурация просто перестала соответствовать нагрузке.
Другая ситуация возникает, когда ресурсов достаточно, приложение настроено нормально, но сервер регулярно становится недоступным из-за инфраструктурных проблем провайдера. Тогда имеет смысл оценивать уже надежность площадки, качество сети и технической поддержки.
При выборе VPS поэтому полезно смотреть не только на количество ядер, объем памяти и стоимость тарифа. Для рабочего сайта не менее важны стабильность инфраструктуры, возможность открыть серверную консоль при потере сетевого доступа, резервное копирование, мониторинг и способность поддержки быстро разобраться с аварией.
Порядок проверки, если сервер внезапно перестал отвечать
Чтобы во время аварии не метаться между DNS, приложением и настройками Linux, можно придерживаться одного порядка действий.
- Проверьте доступность сайта или сервера из другой сети.
- Посмотрите состояние VPS в панели провайдера.
- Попробуйте открыть серверную консоль.
- Сравните IP домена с реальным IP сервера.
- Определите, работает ли SSH или RDP.
- Если вход доступен, проверьте CPU, память и свободное место.
- Проверьте веб-сервер, приложение и базу данных.
- Вспомните, что менялось непосредственно перед сбоем.
- Посмотрите системные журналы и логи сервисов.
- Проверьте firewall и внешние системы защиты.
- Если проблема выглядит сетевой, сравните доступность из разных сетей.
- Если причина остается непонятной, передайте собранные данные поддержке.
Такой подход позволяет быстро разделить три совершенно разные ситуации: действительно упал VPS, нарушилось сетевое соединение или перестало работать приложение внутри исправного сервера.
Именно это разделение важнее всего. Пока владелец говорит просто сервер не отвечает, причин может быть десятки. Как только становится понятно, что виртуальная машина запущена, консоль работает, SSH доступен, а не отвечает только веб-приложение, огромная часть вариантов исчезает.
Поэтому при недоступности сервера сначала ищите границу, до которой все еще работает. Она почти всегда приводит к настоящей причине быстрее, чем перезагрузка, смена DNS и случайное редактирование конфигурации.
