Диагностика высокого пинга до VPS или выделенного сервера

Высокий пинг до VPS или выделенного сервера может приводить к задержкам при подключении по SSH, медленной загрузке сайтов, проблемам с удалённым рабочим столом и нестабильной работе сетевых приложений.
Причина не всегда заключается в самом сервере. Задержки могут возникать из-за большого расстояния между пользователем и дата-центром, перегрузки сети, проблем на стороне интернет-провайдера или потери пакетов на одном из участков маршрута.
В этой статье рассмотрим, как проверить задержку до сервера Linux, проанализировать сетевой маршрут с помощью ping, traceroute и MTR, а также определить, на каком участке сети возникает проблема.

1. Что такое пинг и каким он должен быть

Пинг (ping) — это время, за которое сетевой пакет отправляется от устройства пользователя до сервера и возвращается обратно. Время измеряется в миллисекундах (мс).
Например, если пинг составляет 50 мс, это означает, что полный цикл отправки и получения ответа занимает примерно 50 миллисекунд.
Задержка зависит от нескольких факторов:

• Географического расстояния между пользователем и сервером.
• Маршрута, по которому передаются пакеты.
• Качества соединения между интернет-провайдерами.
• Загрузки сетевого оборудования и каналов связи.
• Наличия потерь пакетов и повторных передач.
• Текущей нагрузки на сетевое оборудование и сам сервер.

Ориентировочные значения пинга:

Пинг	Оценка
1–10 мс	Очень низкая задержка, обычно характерная для близко расположенных узлов
10–30 мс	Низкая задержка
30–60 мс	Умеренная задержка
60–100 мс	Повышенная задержка для интерактивных приложений, но нормальная для удалённых серверов на значительном расстоянии
Более 100 мс	Может быть нормальным для удалённых регионов, но требует проверки, если задержка неожиданно выросла
Более 200 мс	Высокая задержка для большинства интерактивных задач, особенно если сервер расположен относительно близко

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

2. Проверка пинга до сервера с помощью ping

Первый шаг — измерить задержку между вашим компьютером и сервером.
В Linux выполните:
ping -c 20 8.8.8.8
Замените 8.8.8.8 на IP-адрес вашего сервера.
Параметр -c 20 указывает отправить 20 пакетов, после чего команда завершится автоматически.
Пример результата:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=2.13 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=2.20 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=2.95 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=2.23 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=3.09 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=2.58 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=2.13 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=2.71 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=117 time=2.54 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=117 time=2.35 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=117 time=2.58 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=117 time=2.84 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=117 time=2.35 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=117 time=3.12 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=117 time=2.38 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=117 time=2.48 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=117 time=2.67 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=117 time=2.54 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=117 time=2.79 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=117 time=2.66 ms

--- 8.8.8.8 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19028ms
rtt min/avg/max/mdev = 2.127/2.565/3.122/0.287 ms

Обратите внимание на следующие показатели:

• min — минимальное время ответа.
• avg — среднее время ответа.
• max — максимальное время ответа.
• mdev — стандартное (среднеквадратичное) отклонение задержки.
• packet loss — процент потерянных пакетов.

В приведённом примере средний пинг составляет около 2.565 мс, а потери отсутствуют. Разница между минимальной и максимальной задержкой небольшая, поэтому соединение выглядит стабильным.
Если же задержка колеблется, например, от 30 до 250 мс, стоит проверить маршрут и возможную перегрузку сети.

Как проверить пинг в Windows

Откройте командную строку (CMD) и выполните:
ping -n 20 8.8.8.8
В Windows параметр -n задаёт количество запросов, тогда как в Linux используется -c.

Что делать, если пинг не проходит

Если команда сообщает о потере всех пакетов, это ещё не означает, что сервер недоступен. Некоторые сети и серверы фильтруют ICMP-запросы.
Проверьте, доступен ли сервер по SSH:
ssh user@IP_ADDRESS
Также можно проверить доступность нужного TCP-порта:
nc -vz IP_ADDRESS 22
Если SSH работает, а ответы на ping отсутствуют, проблема может заключаться исключительно в фильтрации ICMP.

3. Проверка сетевого маршрута с помощью traceroute

Если пинг до сервера высокий, необходимо определить, через какие узлы проходит трафик.
Для этого используется traceroute.
В Debian и Ubuntu установите утилиту:
apt update
apt install traceroute
Затем выполните:
traceroute -q 5 -w 1 8.8.8.8
Здесь:

-q 5 — отправлять 5 проб на каждый узел.

-w 1 — ждать ответ не более 1 секунды.

8.8.8.8 — целевой IP-адрес.

Пример вывода:

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max
  1  148.227.170.1  0.931ms  0.855ms  0.847ms  0.460ms  0.614ms
  2  172.19.254.227  0.249ms  0.380ms  0.337ms  0.288ms  0.658ms
  3  172.19.254.226  0.503ms  0.228ms  0.919ms  0.862ms  1.187ms
  4  109.236.95.105  2.380ms  2.974ms  2.303ms  2.276ms  2.034ms
  5  *  *  *  *  *
  6  74.125.243.81  2.199ms  2.226ms  1.863ms  2.067ms  2.213ms
  7  8.8.8.8  2.275ms  2.332ms  2.150ms  2.422ms  2.492ms

Каждая строка соответствует очередному сетевому узлу на маршруте до сервера.
Пять значений времени показывают задержку для пяти пробных запросов.
Если задержка увеличивается постепенно, это обычно объясняется прохождением через дополнительные сетевые узлы и расстоянием между ними.
Если на одном из узлов появляются звёздочки:

5  * * * * *

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

4. Как определить проблемный участок с помощью MTR

MTR объединяет возможности ping и traceroute. Утилита многократно проверяет сетевые узлы на маршруте и показывает задержки и потери пакетов.
Это один из наиболее удобных инструментов для диагностики высокого пинга до VPS или выделенного сервера.

Установка MTR

В Debian и Ubuntu:
apt update
apt install mtr

Запуск диагностики

Выполните команду:
mtr -o "LSDNABWV" -s 1000 -nrc 1000 8.8.8.8
Здесь:

-o "LSDNABWV" - задаёт порядок и состав столбцов в отчёте.
-s 1000 - устанавливает размер пробного пакета в 1000 байт.
-n -не преобразует IP-адреса в доменные имена.
-r - формирует итоговый отчёт вместо интерактивного режима.
-c 1000 - отправляет 1000 пробных пакетов каждому узлу маршрута.

Что означают буквы в -o "LSDNABWV"

Эта опция определяет, какие столбцы будут отображаться в отчёте MTR и в каком порядке.

Буква	Столбец	Значение
L	Loss%	Процент потерь пакетов
S	Snt	Количество отправленных пакетов
D	Drop	Количество потерянных пакетов
N	Last	Время отклика последнего полученного пакета
A	Avg	Средняя задержка
B	Best	Минимальная задержка
W	Wrst	Максимальная задержка
V	StDev	Стандартное отклонение задержки

Для диагностики желательно запускать MTR непосредственно с компьютера, на котором наблюдается проблема.
Пример вывода:

HOST: virterion.srv              Loss%  Snt Drop  Last  Avg  Best  Wrst StDev
  1.|-- 148.227.170.1              1.0%  1000    1  1.2  0.7  0.3  1.7  0.3
  2.|-- 172.19.254.227             0.0%  1000    0  0.9  0.7  0.3  1.4  0.3
  3.|-- 172.19.254.222            68.0%  1000  68  0.6  0.7  0.3  1.4  0.3
  4.|-- 109.236.95.107            56.0%  1000  56  2.6  2.4  1.8  3.2  0.3
  5.|-- 72.14.195.126              0.0%  1000    0  3.5  3.6  2.9  5.9  0.4
  6.|-- 72.14.239.107              0.0%  1000    0  2.5  2.7  2.0  3.9  0.3
  7.|-- 172.253.71.199            0.0%  1000    0  2.6  2.7  2.1  3.6  0.3
  8.|-- 8.8.8.8                    0.0%  1000    0  2.2  2.6  2.0  3.4  0.3

Потери на узлах 3 и 4 не продолжаются на следующих узлах и на конечном сервере, значит, эти маршрутизаторы просто ограничивают ответы на диагностические пакеты, а транзитный трафик не страдает.

Как интерпретировать потери пакетов
Рассмотрим другой пример:

HOST: virterion.srv              Loss%  Snt Drop  Last  Avg  Best  Wrst StDev
1.|-- 148.227.170.1      0.0%  1000    0  1.2  0.7  0.3  1.7  0.3
2.|-- 172.19.254.227      0.0%  1000    0  0.9  0.7  0.3  1.4  0.3
3.|-- 172.19.254.222    15.0%  1000  15  0.8  0.9  0.3  2.4  0.4
4.|-- 203.0.113.1        16.0%  1000  16  32.1  32.5  31.4  45.5  2.1
5.|-- 203.0.113.10      16.0%  1000  16  35.1  35.8  33.4  48.5  3.1

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

Как определить участок, на котором увеличивается задержка

Сравните средние значения Avg на последовательных узлах.
Например:
Узел 1: 1 мс.
Узел 2: 8 мс.
Узел 3: 12 мс.
Узел 4: 95 мс.
Конечный сервер: 98 мс.
Резкий рост задержки между третьим и четвёртым узлами может указывать на увеличение времени прохождения по этому участку или изменение маршрута.
Однако это ещё не доказывает перегрузку конкретного маршрутизатора или канала. Необходимо сопоставить результаты с потерями пакетов, повторными измерениями и, при необходимости, MTR в обратном направлении.

5. Проверка маршрута в обе стороны

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

1. Запустить MTR с компьютера пользователя до IP-адреса сервера.
2. Запустить MTR с сервера до публичного IP-адреса пользователя.

На сервере Linux выполните:
mtr -o "LSDNABWV" -s 1000 -nrc 1000 PUBLIC_USER_IP
Вместо PUBLIC_USER_IP укажите публичный IP-адрес пользователя.
Если задержка или потери наблюдаются только в одном направлении, это поможет сузить область поиска.
При этом обратный MTR не всегда полностью воспроизводит исходный маршрут: сетевые пути могут различаться, а ICMP-ответы могут обрабатываться иначе, чем обычный TCP-трафик.
Если пользователь находится за NAT, VPN или корпоративным файрволом, указывайте адрес, видимый серверу, а не локальный адрес компьютера.

6. Как отличить проблему на сервере от проблем у интернет-провайдера

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

• С домашнего интернета пинг составляет 150 мс.
• С мобильного интернета — 35 мс.
• С другого сервера в том же дата-центре — 3 мс.

Такие результаты указывают на то, что проблему стоит искать в домашней сети пользователя, у его интернет-провайдера или на маршруте от него до дата-центра.
Если высокий пинг наблюдается из нескольких независимых сетей, следует проверить маршрут, сетевую инфраструктуру дата-центра и сам сервер.

Проверьте нагрузку на сервер

Подключитесь к серверу по SSH и выполните:
uptime
Команда покажет время работы системы и значения Load Average.
Затем проверьте использование ресурсов:
top
Для анализа памяти:
free -h
Для анализа сетевого интерфейса:
ip -s link
Обратите внимание на счётчики errors и dropped в выводе ip -s link. Рост этих значений во время возникновения проблемы может указывать на проблемы сетевого интерфейса или обработки пакетов.
Однако отдельные значения dropped не всегда означают неисправность: необходимо оценивать динамику счётчиков и сопоставлять её с другими симптомами.

Проверьте доступность внешних узлов с сервера

Например:
ping -c 20 8.8.8.8
Если сервер без потерь и с низкой задержкой обращается к внешнему узлу, это подтверждает работоспособность данного направления, но не исключает проблем на маршруте между сервером и конкретным пользователем.
Если проблема наблюдается только у клиентов определённого интернет-провайдера или из конкретной страны, необходимо отдельно исследовать соответствующее направление маршрутизации.

7. Как проверить, не связан ли высокий пинг с перегрузкой сети

Иногда задержка резко увеличивается только в определённое время суток. Например, утром пинг составляет 35 мс, а вечером — 150 мс.
Возможные причины:

• Перегрузка сети интернет-провайдера.
• Насыщение транзитного канала между операторами.
• Перегрузка канала связи в определённом направлении.
• Очереди пакетов при высокой сетевой нагрузке.
• Проблемы домашнего маршрутизатора или Wi-Fi.

Для проверки запустите MTR в период нормальной работы и в момент возникновения проблемы.
Сравните:

• Средний пинг до конечного сервера.
• Максимальную задержку.
• Процент потерь.
• Узлы, на которых впервые появляется устойчивое ухудшение.
• Изменения маршрута между измерениями.

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

8. Что делать, если высокий пинг наблюдается только из определённой страны

Отдельная ситуация — когда VPS расположен в Европе, но пользователи из другой страны жалуются на высокий пинг или потери пакетов.
Например, сервер находится в Нидерландах, а проблема возникает у пользователей из России.
В таком случае необходимо проверить:

1. Маршрут от пользователя до IP-адреса сервера.
2. Потери пакетов на промежуточных узлах.
3. Задержку до конечного сервера.
4. Наличие аналогичной проблемы у пользователей других интернет-провайдеров.
5. Изменения маршрутизации в момент возникновения проблемы.
6. Обратный маршрут от сервера к пользователю.

Если пинг и потери ухудшаются только на одном направлении, это может указывать на проблему маршрутизации или соединения между операторами связи.
При этом расположение проблемного узла в определённой стране само по себе не доказывает, что причина находится именно в этой стране или у конкретного оператора.
Также важно учитывать, что некоторые промежуточные узлы могут ограничивать ответы на ICMP-запросы, не влияя на передачу обычного трафика.
Если сервер используется для VPN, необходимо отдельно проверить подключение через VPN и обычный доступ к серверу. Результаты могут отличаться из-за особенностей маршрутизации, туннелирования и ограничений сети.

9. Как правильно подготовить данные для обращения в техническую поддержку

Если вы не можете самостоятельно определить причину высокого пинга, подготовьте диагностические данные.
Для этого:

1. Выполните 20–100 запросов ping до IP-адреса сервера.
2. Запустите MTR до того же IP-адреса.
3. Повторите измерения в момент возникновения проблемы.
4. Укажите страну и интернет-провайдера, через которого выполняется подключение.
5. Сообщите, когда именно начались проблемы и наблюдаются ли они постоянно.
6. При возможности выполните обратный MTR с сервера до публичного IP-адреса пользователя.

Пример команды для MTR:
mtr -o "LSDNABWV" -s 1000 -nrc 1000 IP_ADDRESS
Вместо IP_ADDRESS укажите IP-адрес вашего VPS или выделенного сервера.
Если проблема возникает периодически, полезно приложить несколько отчётов, полученных в разное время.
Важно: диагностические отчёты могут содержать публичные IP-адреса и сведения о маршруте. Перед публикацией в открытом доступе учитывайте, что эти данные могут раскрывать информацию о вашей сетевой инфраструктуре.

Заключение

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

1. ping — измерить задержку и потери пакетов.
2. traceroute — посмотреть путь до сервера.
3. mtr — собрать статистику по всем узлам маршрута.
4. ip -s link — проверить счётчики ошибок сетевого интерфейса.
5. top и uptime — оценить нагрузку на сервер.
6. Обратный MTR — сравнить маршрут от сервера до пользователя.

Если ухудшение наблюдается только у пользователей определённого провайдера или из определённого региона, особенно важно проверить маршрутизацию и потери пакетов на соответствующем направлении.
Чем больше данных собрано непосредственно в момент возникновения проблемы, тем проще определить её источник и выбрать дальнейшие действия.