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

Перед заказом VPS и после переезда полезно измерить реальную задержку и скорость до сервера. Собрали набор рабочих команд — от простого ping до iperf3 — и объяснили, как читать их вывод.

ping: базовая задержка

ping отправляет ICMP-пакеты и меряет время round-trip до сервера. Это первое, что стоит проверить: он показывает саму задержку и стабильность канала (потери и джиттер).

ping -c 10 your-server-ip
# Windows: ping -n 10 your-server-ip

В строке итога смотрите на min/avg/max и потери пакетов. Хороший результат — стабильный avg без разброса и 0% packet loss. Разброс между min и max (джиттер) намекает на перегруженный маршрут:

10 packets transmitted, 10 received, 0% packet loss
rtt min/avg/max/mdev = 41.2/42.8/45.1/1.1 ms

Ориентиры: до 30 мс — отлично, 30–80 мс — комфортно для веба, 80–150 мс — заметно, выше 150 мс — далеко от аудитории. Если ping не проходит, сервер может резать ICMP — это не значит, что он недоступен.

Меряйте не разово, а серией и с разных сетей: результат из офисного Wi-Fi, мобильного интернета и другого города может отличаться в разы. Один короткий замер легко ввести в заблуждение — единичный всплеск на перегруженном узле не говорит о качестве сервера. Для оценки берите средний avg по 20–50 пакетам.

Если ICMP закрыт, проверьте доступность порта напрямую — например, HTTPS-порт через telnet или nc. Успешное подключение к порту говорит, что сервер жив, даже когда ping молчит:

nc -zv your-server-ip 443
# или: telnet your-server-ip 443

traceroute и mtr: где теряется время

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

traceroute your-server-ip
# Windows: tracert your-server-ip

Удобнее mtr — он объединяет ping и traceroute и в реальном времени показывает потери на каждом хопе. Резкий рост задержки на конкретном узле указывает на узкое место:

apt install -y mtr-tiny
mtr --report --report-cycles 30 your-server-ip

В отчёте смотрите колонку Loss%: потери на последнем хопе — проблема сервера, потери на промежуточном, которые дальше исчезают — часто просто rate-limit маршрутизатора и не влияют на трафик.

curl: реальная скорость сайта

Пинг меряет сеть, но пользователю важно время ответа сайта. curl раскладывает запрос по фазам — DNS, установка соединения, TLS и время до первого байта:

curl -o /dev/null -s -w "dns %{time_namelookup}s | connect %{time_connect}s | tls %{time_appconnect}s | ttfb %{time_starttransfer}s | total %{time_total}s\n" https://example.com

Высокий time_connect и time_appconnect при низком ttfb — узкое место в сети (далёкий сервер). Низкий connect, но большой ttfb — тормозит уже само приложение или база на сервере. Это помогает не чинить не то.

Повторите замер дважды подряд: первый прогрев наполняет кэши и открывает keep-alive-соединение, второй показывает «горячее» время, которое чаще всего и видит реальный пользователь. Большая разница между первым и вторым запросом намекает на холодный кэш или медленный TLS-хендшейк, а не на сеть.

iperf3: пропускная способность канала

Пинг и curl не показывают, сколько мегабит реально проходит. Для замера пропускной способности между двумя точками есть iperf3. На сервере запускаем в режиме сервера, на клиенте — тест:

# на VPS (сервер)
apt install -y iperf3
iperf3 -s
# на локальной машине (клиент)
iperf3 -c your-server-ip -t 15

iperf3 покажет фактическую скорость в обе стороны. Добавьте -R для реверс-теста (скорость от сервера к вам) — как раз этот показатель важен для отдачи сайта и файлов.

iperf3 -c your-server-ip -t 15 -R

Если iperf3 развернуть негде, грубую оценку скорости отдачи даст скачивание тестового файла с сервера через curl или wget с выводом средней скорости. Это не так точно, как iperf3, но показывает порядок величины и ловит явные проблемы с каналом:

curl -o /dev/null -s -w "avg speed: %{speed_download} B/s\n" https://example.com/testfile.bin

Частые ошибки диагностики

• Судят по одному ping — меряйте с разных сетей и в разное время суток.
• Считают, что ICMP-блок = сервер лежит — многие хосты режут ping, но сайт работает.
• Путают ширину канала и задержку — гигабитный порт не снижает пинг.
• Тестируют speedtest вместо своего сервера — он меряет до чужого узла, а не до вашего VPS.

Замерьте пинг до дата-центра ещё до заказа — по IP тестового узла провайдера. У MAATRIX локации в UK, США и РФ на AMD EPYC + NVMe: низкий TTFB за счёт близости к аудитории Европы/Америки и быстрого диска.

Частые вопросы