Команда ping: как пользоваться и правильно читать вывод

ping — первая команда, которую запускают, когда «сайт не открывается», «сервер пропал» или нужно быстро понять, отвечает ли узел по сети. Она не проверяет сайт целиком, не ходит по HTTP и ничего не знает о состоянии вашего Nginx, но за несколько секунд показывает базовые вещи: резолвится ли имя, доходит ли пакет, какая задержка и есть ли потери.

ping полезен разработчикам, DevOps-инженерам и владельцам сайтов именно как быстрый первичный тест. Если ping example.com отвечает стабильно, это ещё не значит, что сайт доступен пользователям. Но если уже на этом уровне видны потери, таймауты или странная задержка, расследование стоит начинать с сети, DNS, маршрутизации или фаервола.

Ниже разберём, как пользоваться ping в Linux, macOS и Windows, как читать вывод, какие параметры реально нужны в работе и почему результат команды нельзя трактовать как окончательный вердикт по доступности сайта.

Что делает команда ping

ping отправляет на удалённый хост специальные сетевые пакеты и ждёт ответ. В классическом варианте используется протокол ICMP: команда посылает Echo Request, а удалённая сторона возвращает Echo Reply.

Простейший запуск:

ping example.com

Если всё хорошо, вы увидите строки с ответами и временем прохождения пакета туда-обратно. Это время обычно называют RTT — round-trip time.

Важно понимать границы инструмента.

1) ping проверяет сетевую достижимость хоста, а не сайт — сайт может отдавать 500, 502, 403, иметь просроченный SSL-сертификат или зависшее приложение, но при этом нормально отвечать на ping. Для проверки HTTP-уровня используйте curl, браузер, health check или сервис мониторинга доступности — например, Statuser, который проверяет сайт с заданным интервалом и присылает уведомление при сбое.

2) ping не использует TCP или HTTP — большинство сайтов работают поверх TCP и TLS, а ping обычно использует ICMP. Успешный ICMP-ответ не гарантирует, что открыт порт 443 или что TLS-рукопожатие проходит корректно.

3) ping может быть заблокирован — многие серверы, балансировщики, CDN и корпоративные сети фильтруют ICMP. В таком случае сайт может открываться, а ping будет показывать Request timeout.

4) ping зависит от точки проверки — с вашего компьютера узел может быть доступен, а из другой страны или сети — нет. Это особенно заметно при проблемах с провайдерами, CDN, региональными блокировками и BGP-маршрутизацией.

Если нужно понять, как доменное имя превращается в IP-адрес до запуска ping, полезно отдельно разобрать как работает DNS. А для проверки DNS-записей удобнее использовать dig.

Как запустить ping в Linux, macOS и Windows

Базовая форма одинаковая:

ping host

Вместо host можно указать домен или IP-адрес:

ping statuser.cloud
ping 8.8.8.8
ping 1.1.1.1

Но поведение по умолчанию отличается.

1) Linux — ping работает бесконечно, пока вы не остановите его сочетанием Ctrl+C.

ping example.com

Чтобы отправить определённое число пакетов, используйте -c:

ping -c 4 example.com

2) macOS — поведение похоже на Linux: команда продолжает отправлять пакеты до остановки, а количество пакетов тоже задаётся через -c:

ping -c 4 example.com

3) Windows — по умолчанию ping отправляет 4 пакета и завершает работу.

ping example.com

Чтобы задать количество пакетов, используется -n:

ping -n 10 example.com

Чтобы пинговать бесконечно:

ping -t example.com

Остановить бесконечный ping в Windows можно через Ctrl+C.

Если команда не найдена в Linux, установите пакет с утилитами ICMP. Название зависит от дистрибутива:

sudo apt install iputils-ping
sudo dnf install iputils
sudo pacman -S iputils

В контейнерах ping часто отсутствует, особенно в минимальных образах. Например, в alpine его можно получить через пакет iputils или использовать встроенный busybox ping, если он есть. Если вы отлаживаете сеть в контейнерах, пригодится материал про Docker networking.

Как читать вывод ping

Рассмотрим типичный вывод в Linux:

ping -c 4 example.com

Пример:

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=18.4 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=18.1 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=18.7 ms
64 bytes from 93.184.216.34: icmp_seq=4 ttl=56 time=18.3 ms
 
--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 18.112/18.375/18.702/0.219 ms

Разберём ключевые поля.

1) PING example.com (93.184.216.34) — команда сначала разрешила доменное имя в IP-адрес. Если на этом этапе ошибка, проблема может быть в DNS: неправильная запись, неработающий резолвер, истёкший домен, локальный кэш или блокировка.

2) 56(84) bytes of data — размер полезной нагрузки и фактический размер ICMP-пакета с заголовками. Обычно это поле важно только при диагностике MTU и фрагментации.

3) 64 bytes from ... — ответ получен. Если вместо этого идут таймауты, хост не ответил на ICMP-запрос в заданное время.

4) icmp_seq=1 — порядковый номер пакета. По нему удобно видеть пропуски: если есть icmp_seq=1, icmp_seq=2, icmp_seq=5, значит ответы на 3-й и 4-й запросы не пришли или пришли слишком поздно.

5) ttl=56 — time to live, счётчик переходов по маршрутизаторам, а не время. Каждый узел на пути уменьшает TTL, и когда значение становится нулём, пакет отбрасывается. По TTL можно косвенно судить о длине маршрута, но точное расстояние до сервера показывает только трассировка.

6) time=18.4 ms — задержка туда-обратно, один из самых полезных показателей. Для локальной сети это доли миллисекунды, для удалённых серверов — десятки или сотни миллисекунд. Число зависит от расстояния, маршрута, провайдера, загрузки сети и фильтрации.

7) packet loss — процент потерь. 0% packet loss значит, что все ответы пришли. Стабильные потери требуют внимания, особенно если повторяются в разных тестах.

8) min/avg/max/mdev — минимальная, средняя, максимальная задержка и разброс. В macOS вместо mdev часто используется stddev. Большая разница между min и max говорит о нестабильной задержке: сеть может быть перегружена, маршрут — меняться, Wi-Fi — терять качество.

В Windows вывод выглядит иначе, но смысл тот же:

Reply from 93.184.216.34: bytes=32 time=19ms TTL=56
 
Ping statistics for 93.184.216.34:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 20ms, Average = 19ms

Смотрите на те же показатели: ответы, потери, время, минимум, максимум, среднее.

Полезные параметры ping

У ping много опций, но в ежедневной диагностике чаще всего нужны несколько.

1) Количество пакетов — в Linux и macOS используется -c, в Windows — -n.

ping -c 10 example.com

ping -n 10 example.com

Не делайте вывод по одному пакету: минимум 4–10 запросов дают более адекватную картину, а для нестабильных проблем лучше запускать тест дольше.

2) Интервал между пакетами — в Linux и macOS используется -i.

ping -i 0.2 -c 20 example.com

Команда отправит 20 пакетов с интервалом 0,2 секунды. На публичных серверах не злоупотребляйте маленькими интервалами — это может выглядеть как агрессивный трафик.

3) Таймаут ожидания ответа — в Linux параметр -W задаёт время ожидания ответа для каждого пакета в секундах.

ping -c 4 -W 2 example.com

В Windows используется -w, значение задаётся в миллисекундах:

ping -n 4 -w 2000 example.com

4) IPv4 и IPv6 — если у домена есть и A, и AAAA записи, полезно проверять оба стека отдельно.

ping -4 example.com
ping -6 example.com

Команды одинаковы в Linux, macOS и Windows. Иногда сайт открывается по IPv4, но не работает по IPv6, или наоборот — это частая причина «у части пользователей не открывается».

5) Размер пакета — в Linux/macOS используется -s, в Windows — -l.

ping -s 1400 -c 4 example.com

ping -l 1400 -n 4 example.com

Это помогает при диагностике MTU. Если маленькие пакеты проходят, а большие нет, возможны проблемы с фрагментацией, туннелями, VPN или неправильно настроенным сетевым оборудованием. Подробнее — в материале про MTU, MSS и fragmentation.

6) Не фрагментировать пакет — полезно для проверки MTU. В Linux обычно используется -M do, в Windows — -f.

ping -M do -s 1472 -c 4 8.8.8.8

ping -f -l 1472 8.8.8.8

Число 1472 для IPv4 связано с типичным MTU 1500: 1472 байта данных плюс 28 байт заголовков ICMP/IP. Если такой пакет не проходит, а меньший проходит, нужно искать ограничение MTU на пути.

Типовые ошибки и что они означают

Сообщения ping зависят от ОС, но часто встречаются одни и те же ситуации.

1) Name or service not known, could not find host — доменное имя не разрешается. Проблема может быть в DNS-записях, резолвере, локальном /etc/hosts, VPN, корпоративном DNS или самом домене. Проверьте домен через dig, попробуйте другой DNS-сервер и сравните результат с другой сети.

2) Request timeout — запрос отправлен, но ответ не пришёл вовремя. Это может означать потерю пакета, фильтрацию ICMP, недоступность хоста, перегрузку сети или асимметричный маршрут. Один таймаут среди десятков ответов не всегда критичен, а вот серия таймаутов — повод разбираться.

3) Destination Host Unreachable — узел недоступен с точки зрения маршрутизации. Сообщение может прийти от вашего компьютера, шлюза или промежуточного маршрутизатора. Частые причины: нет маршрута, выключен интерфейс, неверная маска сети, проблема на шлюзе, неправильная маршрутизация в VPN.

4) Destination Net Unreachable — недоступна сеть назначения. Это ближе к проблеме маршрута, чем к проблеме конкретного сервера.

5) TTL expired in transit — пакет ходил по сети слишком долго и был отброшен. Часто указывает на маршрутную петлю или странную маршрутизацию. Для анализа нужен traceroute, tracert или mtr.

6) General failure в Windows — общее сообщение сетевого стека. Причиной может быть VPN-клиент, фаервол, повреждённая конфигурация, отключённый интерфейс, проблема с IPv6 или локальными политиками.

7) Ответ приходит не от того IP — домен мог резолвиться в другой адрес из-за CDN, балансировки, split-horizon DNS, записи в hosts или DNS-кэша. Сравните результат ping, dig и настройки DNS.

Если сайт не открывается в браузере, а ping выглядит нормальным, переходите к проверке HTTP-уровня. Для этого хорошо подходит curl: он покажет код ответа, редиректы, заголовки и ошибки TLS. Также поможет пошаговая инструкция что делать, если не открывается сайт.

Как использовать ping при диагностике сайта и сервера

ping лучше применять не как единственный тест, а как первый фильтр. Практический порядок может быть таким.

1) Проверить домен — сначала пингуем доменное имя (ping -c 4 example.com). Если имя не резолвится, не нужно сразу перезапускать веб-сервер — начните с DNS: записи A/AAAA, NS-серверы, срок делегирования, кэш, локальный резолвер.

2) Проверить IP напрямую — если домен не работает, но вы знаете IP сервера, пингуем его напрямую. Если IP отвечает, а домен нет, проблема почти наверняка в DNS или в том, как домен указывает на инфраструктуру.

3) Сравнить IPv4 и IPv6 — современные домены часто имеют оба типа записей (ping -4 и ping -6). Если IPv6 настроен неправильно, часть клиентов может получать нерабочий путь, и это особенно неприятно, потому что у администратора с IPv4-сети всё будет выглядеть нормально.

4) Проверить шлюз и внешний адрес — если не пингуется ничего внешнее, проверьте локальный шлюз (192.168.1.1), затем публичный адрес вроде 1.1.1.1. Если шлюз отвечает, а внешний адрес нет, проблема может быть у провайдера, на роутере, в VPN или маршрутизации.

5) Проверить HTTP отдельно — если ping проходит, проверьте порт и протокол:

curl -I https://example.com

Сайт может быть сетево доступен, но отдавать 502 Bad Gateway, 503 Service Unavailable, иметь проблемы с TLS или зависать на уровне приложения. В таких случаях ping уже не главный инструмент.

6) Сравнить несколько точек — один тест с вашего компьютера не показывает картину для всех пользователей. Если есть жалобы из конкретного региона или сети, проверяйте из похожей точки: VPS в нужной локации, удалённый сервер или мониторинг с распределёнными проверками. Например, Statuser регулярно проверяет сайт по расписанию и фиксирует момент сбоя, чтобы не полагаться на ручные проверки после того, как проблема уже исчезла.

Потери, задержка и jitter: как интерпретировать результат

Главные показатели ping — потери и задержка. Но их нужно читать аккуратно.

1) Нулевые потери не гарантируют отсутствия проблем — если из 10 пакетов все вернулись, это хороший знак, но он не проверяет приложение, базу данных, TLS, лимиты, очереди и ошибки на backend. Короткий тест также может не поймать редкие сбои.

2) Разовые потери не всегда означают аварию — один потерянный пакет на длинном тесте может быть следствием Wi-Fi, перегруженного канала или приоритизации трафика. Но если потери повторяются сериями или совпадают с жалобами пользователей, это значимый сигнал.

3) Средняя задержка может обманывать — среднее avg сглаживает всплески. Если min=20 ms, avg=35 ms, а max=500 ms, пользователи могут ощущать подвисания, хотя среднее выглядит терпимо. Смотрите на максимум и разброс.

4) Высокий jitter ухудшает интерактивные сервисы — jitter — это разброс задержки между пакетами. Для обычной загрузки страниц он тоже неприятен, но особенно заметен в голосе, видео, играх, WebRTC и realtime-интерфейсах.

5) Wi-Fi часто портит картину — если вы пингуете с ноутбука по Wi-Fi, потери и скачки задержки могут быть локальной проблемой. Для диагностики сервера лучше сравнить результат с проводного подключения или с другого сервера в дата-центре.

6) ICMP может иметь низкий приоритет — некоторые маршрутизаторы отвечают на ICMP медленно или ограничивают его, но при этом нормально пересылают TCP-трафик. Поэтому плохой ping до промежуточного узла не всегда означает, что через него плохо проходит пользовательский трафик.

Для анализа маршрута между точками удобнее не обычный ping, а mtr: он показывает потери и задержки по каждому hop. Если нужно понять, где именно начинается деградация, посмотрите разбор как читать трассировку в mtr и WinMTR.

Когда ping бесполезен или вводит в заблуждение

ping хорош как быстрый тест, но у него есть ограничения, из-за которых легко сделать неверный вывод.

1) ICMP заблокирован, а сайт работает — администратор мог запретить ответы на Echo Request на сервере, фаерволе или балансировщике. Многие инфраструктуры так делают для снижения шума и лишней видимости. В этом случае ping покажет таймауты, но https://example.com будет открываться.

2) ICMP работает, а сайт лежит — сервер отвечает на уровне сети, но веб-сервер остановлен, приложение упало, база недоступна, закончились файловые дескрипторы или балансировщик отдаёт 502. Для пользователя сайт недоступен, а ping при этом зелёный.

3) CDN отвечает вместо origin-сервера — если сайт за CDN, ping идёт до ближайшего edge-узла, а не до вашего backend. Он покажет доступность CDN, но не состояние origin-сервера, приложения или базы.

4) Anycast меняет точку назначения — публичные DNS и CDN часто используют anycast. Один и тот же IP может вести в разные дата-центры в зависимости от вашей сети. Результат ping из Москвы и Владивостока может относиться к разным физическим узлам.

5) Балансировка скрывает проблему одного backend — домен может резолвиться в несколько IP, а ping проверит только один адрес. Если один backend болен, а другой здоров, результат будет зависеть от того, куда попал запрос.

6) Права и политики ОС влияют на запуск — в некоторых системах отправка ICMP требует специальных возможностей. В Linux это обычно решается через capability cap_net_raw для бинарника ping, но в контейнерах и ограниченных окружениях могут быть запреты.

Вывод простой: ping отвечает на вопрос «есть ли ICMP-ответ от хоста и какая задержка», но не отвечает на вопрос «работает ли сайт для пользователей». Для последнего нужны HTTP-проверки, логи, метрики, алерты и синтетический мониторинг.

Практические примеры команд

Ниже — набор команд, которые часто нужны в реальной диагностике.

1) Быстро проверить доступность домена

ping -c 4 example.com

Windows:

ping -n 4 example.com

2) Проверить стабильность в течение минуты

ping -c 60 example.com

Если интервал по умолчанию 1 секунда, получится около минуты наблюдения.

3) Проверить только IPv4

ping -4 -c 4 example.com

4) Проверить только IPv6

ping -6 -c 4 example.com

5) Проверить большой пакет

ping -s 1400 -c 10 example.com

Windows:

ping -l 1400 -n 10 example.com

6) Проверить MTU без фрагментации

ping -M do -s 1472 -c 4 8.8.8.8

Windows:

ping -f -l 1472 -n 4 8.8.8.8

Если не проходит, уменьшайте размер, например 1464, 1452, 1400, пока ответы не появятся. Так можно приблизительно найти рабочий размер пакета на пути.

7) Пинговать с числовыми адресами без обратного DNS

В Linux полезен параметр -n, чтобы не тратить время на обратное разрешение имён:

ping -n -c 4 8.8.8.8

8) Запустить тихий итоговый режим

В Linux -q выводит только статистику:

ping -q -c 20 example.com

Это удобно для скриптов и быстрой оценки потерь.

9) Проверить локальную сеть

ping -c 4 127.0.0.1
ping -c 4 192.168.1.1

127.0.0.1 проверяет локальный сетевой стек. Адрес роутера — связь до шлюза. Если локальный шлюз не отвечает, внешние сайты можно пока не трогать.

10) Сравнить домен и IP

ping -c 4 example.com
ping -c 4 203.0.113.10

Так можно отделить проблему DNS от проблемы сетевой доступности IP.

FAQ

Можно ли проверить порт через ping?

Нет. Обычный ping не проверяет TCP-порт. Для проверки порта используйте nc, telnet, curl, Test-NetConnection в Windows PowerShell или специализированный мониторинг TCP/HTTP.

Почему сайт открывается, но ping не проходит?

Скорее всего, ICMP заблокирован на сервере, CDN, фаерволе или у провайдера. Это нормальная ситуация. Проверяйте сайт через curl или браузер, а сетевой путь — через mtr/traceroute.

Почему ping проходит, а сайт не работает?

Потому что ping проверяет только ICMP-ответ. Веб-сервер, приложение, база данных, TLS-сертификат или reverse proxy могут быть неисправны, хотя сервер продолжает отвечать на ICMP.

Какой ping считается нормальным?

Зависит от расстояния и сети. Внутри дата-центра это обычно очень малые значения, между городами — выше, между континентами — ещё выше. Смотрите не только на среднее время, но и на потери, максимум и разброс задержки.

ping — базовая, но не примитивная утилита. Она быстро отделяет DNS-проблемы, сетевую недоступность, потери и скачки задержки от ошибок уровня приложения. Но правильная диагностика начинается там, где вы сопоставляете ping с dig, curl, трассировкой, логами и мониторингом. Тогда команда становится не гаданием «работает или нет», а первым точным шагом в расследовании.