Руководства

Не пингуется VPS: что делать, если сервер недоступен

12 ноября 2026 · 7 мин чтения

Сервер не пингуется — это не всегда авария. Иногда ping просто запрещён настройками, а сайт и SSH работают; иногда сервер действительно недоступен из-за выключенной машины, ошибки в настройке сети или firewall, проблемы на пути до дата-центра. Ниже — порядок проверки: как за пару минут понять, что именно не работает и у кого, что посмотреть в консоли сервера, когда виновата сеть вашего интернет-провайдера и что отправить в поддержку, чтобы проблему решили с первого письма.

Шпаргалка: симптом → причина

Что видите	Вероятная причина	Куда смотреть
Ping не идёт, а сайт и SSH работают	Входящий ICMP запрещён firewall	Ничего не сломано — см. раздел ниже
Не работает только у вас, с check-host всё отвечает	Сеть вашего провайдера или маршрут до дата-центра	mtr, другой интернет
Не отвечает ни у кого, в панели сервер выключен или приостановлен	Выключение, неоплата, работы у провайдера	Панель, почта
В панели «работает», но снаружи тишина	Сеть внутри сервера или firewall	VNC-консоль
Пропало после правки firewall, netplan или перезагрузки	Ваша последняя настройка	VNC-консоль, откат изменения
Пинг есть, но с большими потерями и скачками	Перегрузка канала или атака	mtr, загрузка сервера

Шаг 1. Только у вас или у всех

Первое, что нужно понять, — сервер недоступен вообще или только из вашей сети. Откройте check-host.net, введите IP сервера и запустите проверку ping и TCP-порта (22 для SSH, 443 для сайта): сервис проверит доступность из десятков городов, включая российские.

Из большинства точек отвечает — с сервером всё в порядке, проблема между вами и ним. Переходите к шагу 5.
Не отвечает ниоткуда — проблема на стороне сервера или дата-центра. Переходите к шагу 3.

Быстрая альтернатива — попробовать с мобильного интернета: если с телефона сервер открывается, а с домашнего Wi-Fi нет, дело в сети, а не в сервере.

Шаг 2. Ping молчит, но сайт работает

Ping использует протокол ICMP, и его часто запрещают ради скрытности. Отсутствие ответа на ping не значит, что сервер недоступен. Проверьте сам нужный порт.

Из Linux или macOS:

nc -vz IP_СЕРВЕРА 22

Из PowerShell в Windows:

Test-NetConnection IP_СЕРВЕРА -Port 22

Если порт открыт (succeeded или TcpTestSucceeded : True) — сервер работает, просто не отвечает на ping. Частые причины:

Windows Server по умолчанию блокирует входящий ping. Если он нужен, например для мониторинга, включите правило в PowerShell на сервере:
```
Enable-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)"
```
Linux: ICMP режет правило iptables или nftables, либо включён параметр ядра net.ipv4.icmp_echo_ignore_all=1. Проверить: sysctl net.ipv4.icmp_echo_ignore_all. Сам ufw по умолчанию ping пропускает.

Оставлять ping закрытым — нормально. Но если вы следите за сервером по ping, мониторинг будет бить тревогу зря: проверяйте TCP-порт или HTTPS.

Шаг 3. Посмотреть в панель провайдера

Если сервер не отвечает ни на что и ни из одной точки, откройте личный кабинет провайдера:

Сервер выключен — включите. Если выключается сам, смотрите консоль: возможно, система не загружается.
Услуга приостановлена — чаще всего из-за неоплаченного счёта. Оплатите, и сервер вернётся; данные при короткой приостановке обычно сохраняются, но сроки лучше не испытывать.
Есть уведомление о работах или блокировке — проверьте также почту, привязанную к аккаунту. Провайдер может временно отключить адрес при сильной DDoS-атаке или по жалобе на рассылку и взломанный сервер. В этом случае ответ знает только поддержка.

Шаг 4. Сервер «работает», но недоступен: VNC-консоль

Если в панели сервер включён, а снаружи тишина, войдите через консоль VNC в панели — она работает в обход сети, как монитор и клавиатура. Дальше по порядку.

Есть ли у сервера адрес и маршрут:

ip a
ip route

У сетевого интерфейса должен быть ваш публичный IP, а в маршрутах — строка default via .... Если адреса или маршрута нет — сломалась настройка сети. Частый случай — правка /etc/netplan/*.yaml с ошибкой в отступах. Проверьте файл, исправьте и примените:

sudo netplan try

Команда netplan try сама откатит изменения через две минуты, если вы не подтвердите их, — безопасный способ экспериментировать с сетью.

Выходит ли сервер в интернет:

ping -c 4 8.8.8.8
ping -c 4 ya.ru

Если IP отвечает, а имя нет — проблема с DNS-резолвером на сервере; на входящие подключения это не влияет. Если не отвечает и IP — проблема в сети сервера или у провайдера.

Не закрыл ли всё firewall:

sudo ufw status verbose
sudo iptables -S | head -30
sudo nft list ruleset | head -50

Классика — включённый ufw без правила для SSH или политика DROP в iptables. Быстро вернуть доступ: sudo ufw allow OpenSSH, затем разобраться с остальными правилами. Если вы недавно ставили fail2ban, проверьте, не заблокирован ли ваш собственный IP: sudo fail2ban-client status sshd.

Загрузилась ли система. Если в консоли видна ошибка загрузки, kernel panic или запрос проверки диска — сервер не дошёл до сети вовсе. Сохраните снимок экрана консоли и напишите в поддержку.

Шаг 5. Не работает только у вас: проверить маршрут

Если с check-host сервер отвечает, а от вас нет, посмотрите, где обрывается путь. В Linux и macOS:

mtr -rwc 100 IP_СЕРВЕРА

В Windows — tracert IP_СЕРВЕРА или программа WinMTR. Читать результат просто:

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

Если сервер недоступен из сетей одного или нескольких российских операторов, а из других стран и сетей работает, возможно, адрес или подсеть ограничены на стороне операторов связи. С этим вы со своей стороны ничего не сделаете — расскажите поддержке хостинга, что видите, и спросите о возможных вариантах. Подробнее о том, как измерять и читать задержки, — в статье «Высокая задержка».

Что отправить в поддержку

Чем точнее описание, тем быстрее ответ. В тикете укажите:

IP-адрес сервера и время, когда пропала связь, с часовым поясом;
ссылку на результат проверки check-host;
вывод mtr или tracert со своей стороны;
что вы видите в VNC-консоли и что уже сделали: перезагрузка, проверка firewall, правки сети;
менялось ли что-то перед сбоем.

Как не оказаться здесь снова

Включите мониторинг доступности. Он сообщит о проблеме раньше клиентов. У провайдера есть мониторинг с автоматическим тикетом в поддержку — бесплатно до 10 проверок; свой мониторинг на Uptime Kuma — в статье «Мониторинг серверов». Проверяйте порт или HTTPS, а не только ping.
Меняйте firewall и сеть с подстраховкой. Держите открытой вторую SSH-сессию, пока не проверите, что новое подключение проходит. Для сети используйте netplan try, а перед рискованной правкой firewall запланируйте откат: sudo sh -c 'sleep 300; ufw disable' & — если всё прошло хорошо, просто завершите этот процесс.
Держите бэкапы вне сервера. Если сервер не поднимается вовсе, данные восстановятся на новом — см. «Сервер для бэкапа».

Если сервер доступен, но сайт не открывается или выдаёт ошибки, — это уже другая история: порядок действий в статье «Сайт упал: диагностика за 15 минут».

Мониторинг доступности — бесплатно Start в Финляндии — $10/мес

Коротко

Ping молчит, а порт открыт — сервер работает, просто ICMP запрещён; проверяйте порт через nc или Test-NetConnection.
Сначала проверьте с check-host и мобильного интернета: недоступно у всех или только у вас.
Не отвечает ни у кого — панель провайдера: выключен, приостановлен, есть уведомление.
«Работает», но недоступен — VNC-консоль: ip a, ip route, firewall, fail2ban.
Только у вас — mtr покажет, где обрывается путь.
В поддержку — IP, время, check-host, mtr и что уже сделали.