В комментариях к прошлой подборке спросили: «Как понять, где проблема — на сервере или у провайдера?». И вопрос сейчас в целом актуальный, ведь теперь интернет не всегда стабилен, и непонятно, или упал сервер, или лёг канал, или с сетью беды. Эта подборка — про инструменты, которые отвечают на этот вопрос.
Шаг 1. Ping
Начну с простого, тех, кому интересны внешние инструменты, прошу пролистать ниже. Если вы не можете попасть на сервер, первое, что нужно сделать, — пингануть его внешний IP:
ping -c 10 your.server.ip
Флаг -c 10 задаёт десять пакетов. На Windows — просто ping your.server.ip, остановится сам через четыре пакета.
В выводе смотрите на rtt min/avg/max — время отклика. Если средний RTT вырос с привычных 40 до 300 мс, условия на маршруте изменились. Чтобы понять, где именно возникла задержка, сравните результат с другими адресами и повторите проверку из другой сети, например, через мобильный интернет.
Для сравнения пропингуйте другие адреса и повторите проверку из другой сети:
ping -c 10 1.1.1.1 ping -c 10 your.server.ip
Также важен packet loss — это потери. Нулевые потери означают, что сервер ответил на все отправленные ICMP-запросы. Однако это ещё не доказывает, что сайт, SSH или другое приложение работает, поскольку TCP-порты могут быть недоступны отдельно.
Потери в 10–50% могут указывать на перегрузку или повреждение канала, но иногда маршрутизаторы просто ограничивают ответы на ICMP. При 100% потерь сервер может быть выключен, пакеты могут не доходить до него или ICMP может быть заблокирован файрволом.
Шаг 2. Traceroute
Дальше ping показывает проблему, но не говорит, где она. Для этого нужен traceroute:
# Linux traceroute your.server.ip # Быстрый traceroute с ICMP вместо UDP traceroute -I your.server.ip # Windows tracert your.server.ip
Каждая строка — один маршрутизатор. Часто, если пакеты доходят до 8-го хопа, а на 9-м начинают теряться, то проблема за пределами вашей сети, на магистральном канале или в дата-центре. Если обрыв на 2-3-м хопе — это ваш провайдер. Однако номера хопа могут различаться так же, как прямой и обратный маршруты.
Для наблюдения за маршрутом в течение некоторого времени удобнее использовать mtr. Это гибрид ping и traceroute, который собирает статистику по каждому хопу:
sudo apt install mtr-tiny mtr --report --report-cycles 100 your.server.ip
Mtr покажет Loss% и Last/Avg/Best/Wrst для каждого хопа. Смотрите прежде всего на конечный адрес. Потери на одном промежуточном хопе, которые исчезают дальше, обычно связаны с ограничением ICMP-ответов. Если потери начинаются на определённом участке и сохраняются до конечного узла, проблема, вероятно, находится на этом участке или перед ним. Для надёжного вывода полезно запустить MTR в обе стороны и из нескольких сетей.
Шаг 3. Dig
Иногда сервер работает, но доменное имя указывает не на тот IP или вообще не разрешается. Поэтому перед проверкой сайта стоит отдельно посмотреть DNS:
# IPv4 dig +short A your-site.com # IPv6 dig +short AAAA your-site.com # Проверка через определенный DNS-сервер dig @1.1.1.1 your-site.com
Сравните полученный адрес с внешним IP вашей VDS. Отдельно проверьте запись AAAA. Бывает, что сайт нормально работает по IPv4, но не открывается у части пользователей из-за сломанной конфигурации IPv6. Посмотреть весь путь разрешения имени можно так:
dig +trace your-site.com
Если разные DNS-серверы возвращают разные результаты, проблема может быть связана с обновлением записей, кешированием или конфигурацией авторитетных DNS-серверов.
Шаг 4. Curl
Если сервер пингуется, но сайт не открывается, значит, проверку нужно продолжить на уровнях DNS, TCP, TLS и HTTP. Curl покажет, отвечает ли веб-сервер и какой код статуса возвращает:
# Проверить заголовки curl -I https://your-site.com # Показать код ответа и общее время curl -o /dev/null -sS \ -w "%{http_code} %{time_total}\n" \ https://your-site.com # Показать время соединения и TLS curl -o /dev/null -sS \ -w "code=%{http_code} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" \ https://your-site.com # Следовать редиректам curl -L -I https://your-site.com # Проверить сайт через определенный IP curl --resolve your-site.com:443:your.server.ip \ https://your-site.com
Команда curl -I отправляет запрос HEAD. Некоторые приложения обрабатывают его иначе, чем обычный GET. Если результат выглядит странно, повторите проверку без -I. Для подробной диагностики пригодится:
curl -v --connect-timeout 5 https://your-site.com/
В выводе будут видны разрешение имени, подключение к IP, TLS-рукопожатие, сертификат и HTTP-заголовки.
Смотрим на статус:
200 — всё хорошо,
301/302 означают перенаправление — нормально оно или нет, зависит от ожидаемого поведения,
403 может быть штатным ограничением доступа, ответом WAF, блокировкой IP или ошибкой конфигурации,
502 означает, что шлюз или прокси получил некорректный ответ от вышестоящего сервиса (это необязательно nginx),
503 может означать перегрузку, обслуживание, отсутствие доступных экземпляров приложения или намеренный отказ,
521 означает, что origin-сервер отклонил соединение Cloudflare — чаще всего это значит, что веб-сервер выключен или Cloudflare заблокирован файрволом,
522 означает тайм-аут между Cloudflare и origin — он возможен как до установления TCP-соединения, так и после него,
523 означает, что Cloudflare не может найти маршрут до origin.
Код 522 самый важный, ведь он говорит, что Cloudflare не смог установить TCP-соединение с вашим сервером. Однако причиной этого может быть origin, его файрвол, неверный IP, перегрузка или проблема маршрутизации между Cloudflare и хостером.
Шаг 5. Ss
Если сервер работает, но приложение не отвечает, нужно проверить, слушает ли приложение нужный порт:
# Все TCP-порты в состоянии LISTEN sudo ss -ltnp # Установленные TCP-соединения sudo ss -tnp state established # Кто слушает порт 443 sudo ss -ltnp 'sport = :443' # Краткая статистика сокетов ss -s
Если нужного сервиса нет среди LISTEN, значит, он не запущен, слушает другой порт или привязан только к определённому интерфейсу. Проверяйте конкретные порты через:
sudo ss -ltnp 'sport = :22' sudo ss -ltnp 'sport = :80' sudo ss -ltnp 'sport = :443'
Если приложение слушает 127.0.0.1:8080, оно будет доступно только локально. Если ожидается прямое внешнее подключение, сервис обычно должен слушать внешний адрес или 0.0.0.0. Локальный TCP-порт можно проверить через nc:
nc -vz -w 3 127.0.0.1 8080
Эта команда подтверждает только возможность установить TCP-соединение, то есть она не проверяет, правильно ли приложение обрабатывает запросы. Если локально порт доступен, а извне нет, проверьте файрвол:
sudo nft list ruleset
На старых системах также можно использовать:
sudo iptables -S
Не забудьте про сетевой экран в панели хостера. Его правила действуют вне гостевой ОС и не отображаются в nftables или iptables.
Шаг 6. Htop / btop
Если сервер отвечает, но медленно, возможно, кончились ресурсы. Проверяем через htop/btop:
sudo apt install htop htop
В первую очередь смотрите на загрузку CPU, память, swap, load average и список процессов.
Если все ядра долго загружены на 100%, приложению может не хватать процессорного времени. Но на VDS стоит дополнительно смотреть на steal time, который в top обозначается как %st. Высокое значение может означать, что процессорное время забирают другие виртуальные машины на том же физическом сервере.
С памятью лучше не ориентироваться только на цвет полосы, ведь Linux использует свободную RAM под кэш и при необходимости освобождает её. Более полезный показатель можно увидеть в колонке available:
free -h
Однако занятое место в swap не говорит о проблеме (там могут находиться давно неиспользуемые страницы). Но задумайтесь, если есть постоянная активность подкачки, снижение производительности, низкое значение available и сообщения OOM Killer.
Альтернатива htop называется btop. Она показывает CPU, память, диски, сеть и процессы в одном интерфейсе:
sudo apt install btop btop Для быстрой проверки без TUI подойдет: uptime free -h ps aux --sort=-%cpu | head -11
Шаг 7. Df / du
Одна из самых частых причин «падения» сервера — переполненный диск. Приложения начинают писать ошибки, логи не ротируются, база данных отказывается принимать записи. Для того, чтобы проверить:
Проверяем свободное место:
df -h
Смотрите на столбец Use% — значение около 90% уже требует внимания, но само по себе не означает отказ. Критический порог зависит от размера диска, файловой системы и настроек приложения. Кроме свободных блоков могут закончиться inode:
df -i
В этом случае место на диске ещё остаётся, но создать новый файл уже невозможно. Такое бывает, когда приложение накопило огромное количество мелких файлов. Посмотреть использование каталогов можно так:
sudo du -xhd1 / 2>/dev/null | sort -h sudo du -xhd1 /var 2>/dev/null | sort -h sudo du -sh /var/log/* 2>/dev/null
Флаг -x не даёт du переходить на другие файловые системы. Найти крупные файлы можно через:
sudo find /var/log -xdev -type f -size +100M -ls
Ещё одна трабла возникает, когда большой лог удалили, но процесс продолжает держать его открытым. df показывает занятое место, а du не может найти файл. Такие дескрипторы проверяются командой:
sudo lsof +L1
Освободить место получится после корректного перезапуска или переоткрытия логов соответствующим процессом.
Шаг 8. Iotop / iostat
Если CPU и память выглядят нормально, но сервер продолжает тормозить, проверяем дисковый ввод-вывод:
sudo apt install iotop sudo iotop -o
Флаг -o оставляет в списке процессы, которые сейчас читают или записывают данные. Постоянная запись со стороны mysqld может быть связана с запросами, журналом транзакций, чекпоинтом или фоновой работой базы. Но по одному iotop нельзя сразу сделать вывод о плохой оптимизации, ведь если много пишет journald, стоит проверить, какой сервис генерирует сообщения.
Расширенную статистику устройств показывает iostat, входящий в пакет sysstat:
sudo apt install sysstat iostat -yxz 1
Флаг -y пропускает первый отчёт со средними значениями с момента загрузки, -x включает расширенную статистику, а -z скрывает неактивные устройства. Смотрите на:
await, то есть среднее время выполнения запроса вместе с ожиданием в очереди,
aqu-sz, среднюю длину очереди,
r/s и w/s, количество операций чтения и записи,
rkB/s и wkB/s, объём передаваемых данных,
%util, долю времени, в течение которого устройство обрабатывало запросы.
На VDS показатели относятся к виртуальному диску. Задержки могут возникать на стороне физического хранилища хостера, хотя внутри виртуальной машины нельзя увидеть его полную нагрузку.
Шаг 9. Vmstat / dmesg
Vmstat показывает процессы, память, подкачку, дисковый ввод-вывод и CPU:
vmstat 2
Число 2 означает обновление каждые две секунды. Первая строка содержит средние показатели с момента запуска системы, а следующие относятся к текущим интервалам.
Колонки si и so показывают скорость чтения данных из swap и записи в него. Одиночные ненулевые значения ещё не означают нехватку памяти. Признаком давления на RAM будет постоянная активность подкачки вместе с низким значением available и ростом задержек.
Колонки bi и bo показывают скорость чтения с блочных устройств и записи на них. Высокий ввод-вывод может быть штатной нагрузкой, поэтому его нужно сопоставлять с await, очередью диска и скоростью работы приложения.
Колонка r показывает число процессов, которые выполняются или ждут процессорного времени. Колонка b показывает процессы, заблокированные в ожидании ввода-вывода.
Сообщения ядра можно посмотреть через dmesg:
# Последние 50 строк sudo dmesg | tail -50 # Найти сообщения о нехватке памяти sudo dmesg | grep -Ei "oom|out of memory|killed process" # Следить за сообщениями в реальном времени sudo dmesg -w
На системах с ограниченным доступом к dmesg используйте журнал ядра:
sudo journalctl -k -g "oom|out of memory|killed process" -i
Если OOM Killer завершил nginx, PostgreSQL или другой процесс, системе действительно не хватило памяти в момент выделения ресурсов. Однако ядро выбирает жертву с учётом oom_score, потребления памяти, ограничений cgroup и других параметров.
Шаг 10. Journalctl / systemctl
Если сервер работает, но приложение упало — смотрите логи systemd:
# Статус сервиса systemctl status nginx --no-pager -l # Логи сервиса в реальном времени journalctl -u nginx -f # Логи сервиса за последний час journalctl -u nginx --since "1 hour ago" # Все ошибки за последний час journalctl -p err --since "1 hour ago" # Логи ядра journalctl -k
Команда systemctl status показывает не только состояние сервиса, но и последние строки логов. Если видите Active: failed — сервис упал. Если Active: activating (auto-restart), то сервис пытается перезапуститься после падения.
Если это состояние повторяется, смотрите полный журнал юнита:
journalctl -u nginx --since today --no-pager
Список всех неработающих юнитов:
systemctl --failed --no-pager
При диагностике смотрите не только на момент падения, ведь причина часто находится на несколько строк или минут раньше, например, перед ошибкой приложения появляется сообщение о заполненном диске, нехватке памяти или недоступности базы данных.
Шаг 11. Speedtest-cli / iperf3
Ну и если сайт тормозит, то нужно понять, это приложение медленное, или канал узкий. В репозиториях Debian и Ubuntu для этого доступен Python-пакет speedtest-cli:
sudo apt install speedtest-cli speedtest-cli Краткий вывод: speedtest-cli --simple
Speedtest-cli проверяет скорость до ближайшего сервера Speedtest. Но он измеряет скорость «в интернет», а не между вами и сервером. Для проверки скорости между вашей машиной и VDS есть iperf3. На сервере:
sudo apt install iperf3 iperf3 -s -1
По умолчанию iperf3 слушает TCP-порт 5201. Разрешите подключение к нему только со своего IP и закройте порт после завершения проверки.
На клиенте:
# Передача от клиента к VDS iperf3 -c your.server.ip # Передача от VDS к клиенту iperf3 -c your.server.ip -R
iperf3 покажет пропускную способность TCP-канала между двумя точками. Если speedtest-cli показывает 500 Мбит/с, а iperf3 между вами и сервером — 2 Мбит/с, то проблема в маршруте между вами и дата-центром, а не в сервере.
Кроме того, если VDS не отвечает по SSH, нужно проверить её через web-консоль, VNC или serial console в панели хостера. Только так можно понять, работает ли гостевая ОС, когда внешняя сеть недоступна.
Внешний мониторинг
Теперь для более опытных — внешние инструменты.
1. SmokePing
Для чего: постоянно мониторить доступность сервера и видеть историю потерь и задержек.
Mtr показывает картину момента, но если проблема плавающая, то запускать его вручную десять раз в день как минимум неудобно. SmokePing периодически шлёт ping, curl и другие запросы к вашим серверам и сервисам, а после строит графики латентности с разбивкой по времени.
Минусы — требует веб-сервера для отображения графиков и периодического запуска через cron или systemd.
2. nmap
Для чего: проверить, какие порты открыты на сервере, и понять, отвечает ли сервис или его блокирует файрвол.
Бывает такое, что сервис работает, а порт закрыт фаерволом, или сервис слушает на localhost вместо внешнего интерфейса, или Docker-контейнер не прокинул порт… Nmap сканирует порты и показывает всё это. Также утилита умеет определять версию сервиса за портом, а это помогает найти устаревшее ПО.
Минусы — полное сканирование всех портов занимает время и может быть расценено хостером как атака. Но для диагностики собственного VDS — маст-хэв.
3. Speedtest-cli
Для чего: проверить реальную скорость интернет-канала сервера.
Если хостер обещает стомегабитный порт, а файлы качаются медленно, то проблема в канале хостера или в сети, через которую вы подключаетесь. Speedtest-cli запускает тест скорости от вашего сервера до ближайших точек измерения — показывает входящую и исходящую скорость, пинг, джиттер.
Если с сервера скорость нормальная, а к вам доходит медленно, то проблема в маршруте между хостером и вашим провайдером. Если скорость с самого сервера низкая — это повод написать в поддержку хостера.
Минусы — тест идёт через публичные серверы Ookla, результат зависит от загруженности конкретной точки измерения. Не показывает скорость до конкретного IP, только до тестовых серверов.
4. Httpie
Для чего: проверить, отвечает ли веб-сервис, и посмотреть заголовки ответа.
Httpie — это удобная альтернатива curl для работы с HTTP. Позволяет отправить запрос к своему серверу и посмотреть полный ответ — статус-код, заголовки, тело, время отклика.
Минусы — только HTTP и HTTPS, для других протоколов не подходит. Зависит от Python, поэтому на минимальной виртуалке точно избыточен.
5. Glances
Для чего: увидеть полную картину состояния сервера в одном окне.
Glances собирает все метрики системы в одном TUI-интерфейсе. Среди показателей: загрузка процессора по ядрам, потребление памяти с разбивкой на used/cached/buffered, дисковый ввод-вывод, сетевой трафик, список процессов с сортировкой по ресурсам. А индикаторы (зелёный, жёлтый, красный) показывают, какие есть проблемки.
Также утилита может работать в режиме веб-сервера, отдавая данные в браузер, и в режиме клиент-сервер, мониторя несколько машин с одного экрана.
Минусы — на слабых тарифах сам агент потребляет ресурсы, плюс для глубокого анализа всё равно нужны специнструменты.
6. lnav
Для чего: найти ошибки в логах, не читая их целиком.
lnav — это просмотрщик логов с подсветкой синтаксиса, автоматическим распознаванием форматов, фильтрацией по уровням (ERROR, WARN, INFO), а также с поиском по регулярным выражениям и возможностью смотреть несколько файлов одновременно в разделённом экране.
Минусы — не умеет агрегировать логи с нескольких серверов — только локальные файлы.
7. Nethogs
Для чего: найти процесс, который зажигает сетевой канал.
Утилита показывает сетевой трафик в реальном времени с разбивкой по процессам: кто отправляет, кто получает, с какой скоростью, на какие IP.
Минусы — требует прав администратора для чтения сетевой статистики процессов и может показывать не все данные.
Ну и наконец
Заведите alias или небольшой скрипт, запускающий базовые проверки одной командой:
#!/bin/bash echo "=== Uptime and load ===" uptime echo echo "=== Disk space ===" df -h echo echo "=== Inodes ===" df -i echo echo "=== Memory ===" free -h echo echo "=== Top CPU processes ===" ps aux --sort=-%cpu | head -6 echo echo "=== Listening TCP ports ===" ss -ltn echo echo "=== Failed services ===" systemctl --failed --no-pager
Сохраните его в /usr/local/bin/healthcheck и сделайте исполняемым:
sudo chmod +x /usr/local/bin/healthcheck
После этого запустить проверку можно так:
healthcheck
Делитесь в комментариях, какие инструменты используете вы для диагностики своих серверов и какие сюрпризы они вам показывали.
© 2026 ООО «МТ ФИНАНС»
sundmoon
Добавили бы в этот гайд диагностику эффектов от ТСПУ и криво настроенных средств их преодоления..