Ping нескольких адресов сразу: как проверять несколько узлов и сравнивать задержку

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

Второй сценарий — контроль нескольких своих серверов или устройств: проверить, какие из них включены и отвечают, и сравнить задержку. Третий — сравнение разных путей, например через проводное и беспроводное подключение.

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

Встроенный ping принимает одну цель, поэтому для списка нужен цикл. В командной строке cmd в интерактивном режиме запись такая: for %h in (192.0.2.1 198.51.100.1 example.com) do ping -n 3 %h. В bat-файле знак процента удваивают: %%h. Вывод получится длинным: для краткости отфильтруйте строки: ping -n 3 %h | findstr /i "Average Среднее Lost потеряно". Слова зависят от языка системы, поэтому укажите оба варианта или используйте фильтр по слову, которое видите в своём выводе.

В PowerShell удобнее командлет Test-Connection: Test-Connection -ComputerName 192.0.2.1, 198.51.100.1, example.com -Count 4. Он принимает список сразу. В Windows PowerShell 5.1 время ответа лежит в свойстве ResponseTime, а в PowerShell 7 — в свойстве Latency, поэтому проверьте вывод в своей версии. Сводку по узлам можно получить группировкой: результаты передают в Group-Object по имени узла и вычисляют среднее через Measure-Object.

Для проверки в фоне PowerShell 7 умеет параллельность: список пропускают через ForEach-Object с параметром -Parallel. В Windows PowerShell 5.1 параллельность достигается через задания, но для небольшого списка последовательной проверки вполне достаточно.

В оболочке bash или zsh цикл выглядит так: for h in 192.0.2.1 198.51.100.1 example.com; do echo "== $h"; ping -c 4 $h | tail -2; done. Команда tail оставляет две последние строки: итог потерь и минимум, среднее и максимум задержки. Пример вывода (пример): «4 packets transmitted, 4 received, 0% packet loss» и «rtt min/avg/max/mdev = 11.2/12.4/14.1/1.1 ms». В macOS вторая строка называется round-trip и не содержит mdev, но смысл тот же.

Чтобы проверять узлы одновременно, запустите пинги в фоне знаком амперсанд и дождитесь завершения командой wait, а вывод перенаправьте в отдельные файлы.

Специальная утилита fping создана для этой задачи. Установка: apt install fping в Debian и Ubuntu, brew install fping в macOS. Пример: fping -c 5 192.0.2.1 198.51.100.1 example.com. Она отправляет пакеты по всем адресам поочерёдно, не ожидая ответа на каждый, и в конце печатает сводку: потери и минимум, среднее и максимум по каждому узлу. Ключ -g позволяет проверить диапазон, например подсеть своей домашней сети, а -f читает адреса из файла.

Смотрите на две вещи: процент потерь и среднюю задержку, а также на разброс. Сравнивайте однотипные узлы: близкие и дальние ведут себя по-разному. Ориентиры сравнения такие.

• Роутер — задержка обычно в пределах единиц миллисекунд по кабелю и заметно больше по Wi-Fi.
• Внешние узлы в вашей стране — десятки миллисекунд.
• Узлы на других континентах — сотни миллисекунд из-за расстояния, это нормально.
• Единственный узел с потерями при остальных чистых — проблема с ним или на пути к нему.
• Все внешние узлы с потерями при чистом роутере — обратите внимание на провайдера.

1. Составьте список: роутер, два-три внешних узла, нужные вам серверы.
2. Выполните проверку по каждому не менее чем по двадцати пакетов.
3. Занесите в таблицу: узел, потери, средняя и максимальная задержка.
4. Повторите в другое время суток и сравните.
5. При расхождениях переходите к mtr для проверки маршрута до проблемного узла.

Для журнала сохраняйте вывод с меткой времени. В Linux и macOS можно поставить цикл с командой date перед каждым запуском и перенаправить результат в файл. В PowerShell добавьте поле времени через Select-Object и экспортируйте таблицу в CSV командой Export-Csv. Записи с меткой времени помогают связать сбои с событиями, например с включением мощного прибора или вечерней нагрузкой.

Не запускайте бесконечные быстрые пинги в сторону чужих серверов: это создаёт лишнюю нагрузку и выглядит как попытка атаки. Интервал в секунду для нескольких узлов приемлем, в остальных случаях делайте паузы. Для длительного мониторинга нескольких узлов вместо самописных циклов лучше подойдёт специальная система наблюдения, если у вас много устройств.

Первая ошибка — проверять слишком мало пакетов: при четырёх пакетах единичная потеря даёт двадцать пять процентов и выглядит катастрофой. Возьмите двадцать и больше. Вторая — сравнивать узлы, до которых очень разное расстояние, и делать вывод о неполадке: нужно сравнивать с тем, что было раньше, а не узлы между собой. Третья — забывать о разрешении имён: если проверять по имени, часть времени и возможных ошибок относится к DNS, а не к сети. Для чистоты картины используйте адреса, а не имена, либо проверьте DNS отдельно.

Четвёртая — не учитывать протокол. Имя может разрешаться в адрес IPv6, и ping пойдёт по нему; принудительно выбрать версию помогут ключи -4 и -6. Пятая — запускать проверку через Wi-Fi и удивляться разбросу: для стабильных выводов подключайтесь по кабелю. Помните, что записи в журнале нужно снабжать временем и режимом подключения.