VDS network troubleshooting: iperf3, mtr, ss и tcpdump — практический разбор

Когда на VDS «всё тормозит»: типовые симптомы и что они означают

Сетевые инциденты на VDS обычно выглядят одинаково: «страница грузится медленно», «API периодически падает по таймауту», «SSH подлагивает», «бэкапы то летят, то стоят». Важно сразу разложить жалобу на измеримые признаки: RTT (задержка), packet loss (потери), jitter (разброс задержки), retransmits (ретрансмиты TCP), bandwidth (пропускная способность).

Частая ошибка в расследовании — пытаться «лечить скорость», не выяснив, что именно ограничивает передачу: маршрут, потери, MTU/PMTUD, очереди (qdisc) и bufferbloat, ограничение по CPU/softirq, либо банально «узкое место» на противоположной стороне.

Ниже собран минимальный, но рабочий набор инструментов: iperf3 (пропускная способность), mtr (маршрут + потери), ss (состояние сокетов и TCP-метрики) и tcpdump (пакетный уровень). Параллельно будем держать в голове системные факторы: qdisc, conntrack, pmtud, nic offload.

Быстрый план диагностики (чек-лист на 10–15 минут)

1. Подтвердить проблему измерением: задержка/потери (mtr), скорость (iperf3), ретрансмиты/очереди (ss).

2. Понять границу: «внутри VDS», «на выходе из DC», «на маршруте», «на удалённой стороне».

3. Если TCP ведёт себя странно: проверить PMTUD/MTU и MSS, а затем уже снимать дампы (tcpdump).

4. Если проблема периодическая: собирать короткие срезы (30–60 секунд) и сравнивать «норма vs плохо».

Подготовка: что поставить и какие права нужны

На Debian/Ubuntu:

sudo apt update
sudo apt install -y iperf3 mtr-tiny tcpdump iproute2 ethtool conntrack

На RHEL-подобных (Alma/Rocky):

sudo dnf install -y iperf3 mtr tcpdump iproute ethtool conntrack-tools

Для tcpdump обычно нужны права root. Если хотите запускать без root, настраиваются Linux capabilities, но для разовой серверной диагностики чаще проще работать через sudo.

Отдельно: если вы только подбираете сервер под сетевую нагрузку (VPN, прокси, балансировка, high PPS), заранее прикиньте требования к CPU и памяти: это часто важнее «номинального канала». См. заметку как выбрать VDS по CPU и RAM под нагрузку.

iperf3: меряем «сырой» канал и отделяем сеть от приложения

iperf3 отвечает на простой вопрос: «какая реальная пропускная способность между точкой A и B в текущих условиях». Это почти всегда первый инструмент, когда подозрение на низкую скорость.

Схема измерений: где держать сервер iperf3

Идеально — иметь вторую контрольную машину (ещё одну VDS) в нужном регионе или в той же площадке. Тогда вы измеряете именно сеть/стек, а не ограничения приложения/диска.

На стороне сервера (точка B):

iperf3 -s

На тестируемой VDS (точка A):

iperf3 -c 203.0.113.10 -t 15

Для оценки влияния параллельных потоков (часто помогает «раскачать» канал, особенно при высоком RTT):

iperf3 -c 203.0.113.10 -t 15 -P 4

Полезно проверить и обратное направление (потоки от сервера к клиенту):

iperf3 -c 203.0.113.10 -t 15 -R

UDP-тесты и как интерпретировать потери

UDP в iperf3 позволяет «задать скорость» и посмотреть, где начинается packet loss и растёт jitter. Это хороший тест на перегруз/очереди (qdisc) и на качество маршрута.

iperf3 -c 203.0.113.10 -u -b 200M -t 15

Если уже на умеренной скорости видите потери и джиттер, варианты обычно такие: перегруз на пути, шейпинг, bufferbloat, либо проблемы на хосте (CPU, softirq, драйвер/virtio, offload).

Если скорость низкая: что проверить до «магии»

• RTT: при большом RTT один поток TCP может упираться в окно и любые потери. Сравните -P 1 и -P 4.

• Ретрансмиты: рост retransmits почти всегда «ест» скорость сильнее, чем кажется.

• CPU/softirq: на VDS бывает, что сеть упирается в CPU, особенно при большом PPS.

• MTU/PMTUD: при «чёрной дыре» ICMP TCP может зависать на больших пакетах.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если для таких замеров и контроля маршрутов вам нужна «вторая точка» в другом регионе или рядом с вашей инфраструктурой, проще всего завести тестовую VDS и держать на ней iperf3/mtr как контрольный стенд.

mtr: маршрут, RTT и потери в одном окне

mtr удобнее, чем ping и traceroute, потому что показывает статистику по каждому хопу: потери, средний RTT, разброс. Для первичной локализации — почти идеален.

Базовый запуск и режим отчёта

Интерактив:

mtr 1.1.1.1

Отчёт (удобно прикладывать к тикету/постмортему):

mtr -rwzbc 200 1.1.1.1

Опции: -c — количество запросов, -r — report, -w — wide, -z — компактный порядок хопов, -b — IP и имена (если нужно).

Как читать потери в mtr и не сделать неправильный вывод

Классическая ловушка: потери на промежуточном хопе не всегда означают реальные потери трафика. Многие роутеры режут или понижают приоритет ICMP TTL exceeded. Критично смотреть на последнюю строку (цель) и на корреляцию: если потери начались на хопе N и сохраняются на всех следующих — это уже похоже на реальную проблему.

Если потери видны только на одном промежуточном хопе, а на следующих хопах и на цели потерь нет, чаще всего это ICMP rate-limit, а не деградация канала.

TCP-mtr: когда ICMP «обманывает»

Иногда ICMP проходит иначе, чем ваш реальный трафик (например, проблема именно с TCP/443). Тогда используйте TCP-пробы:

mtr -rwzbc 200 -T -P 443 example.com

Это помогает приблизиться к реальному поведению HTTPS и увидеть, где растёт RTT или появляются потери именно для TCP.

ss: смотрим TCP-стек, ретрансмиты, очереди и RTT «глазами ядра»

ss показывает то, что ядро Linux реально «думает» о соединениях: очереди send/recv, состояние, TCP-параметры, оценки RTT, ретрансмиты. Когда приложение «таймаутится», очень часто в ss уже видно, что именно тормозит.

Быстро: кто слушает порты и сколько соединений

ss -lntup

Полезно для проверки базовых вещей: сервис вообще слушает, на каком адресе, не перепутан ли bind на 127.0.0.1 вместо публичного IP.

Очереди сокетов и симптом перегруза

Показать TCP-соединения и очереди (Send-Q/Recv-Q):

ss -tn

Большие значения Send-Q на множестве соединений — признак, что сервер пытается отправить, но «в сеть не уходит» (узкое место дальше). Большие Recv-Q — сервер не успевает читать, либо приложение/обработка тормозит.

Ретрансмиты, RTT и «плохие» соединения

Попросим расширенную статистику TCP:

ss -ti

В выводе ищите:

• rtt и rttvar — средняя задержка и её вариативность;

• retrans — признак потерь и перегруза;

• cwnd — окно перегрузки: если «схлопывается», скорость будет прыгать;

• pacing_rate — полезно при современных qdisc и TCP pacing.

Чтобы сфокусироваться на конкретном сервисе (например, 443):

ss -tn sport = :443

Или по удалённому адресу:

ss -tn dst 198.51.100.25

qdisc и bufferbloat: когда «скорость есть», но задержка улетает

Даже без явных потерь сеть может быть «плохой» из-за очередей. Когда канал забивается, пакеты не теряются, а копятся в буфере — RTT растёт, интерактивные запросы (SSH, API) начинают лагать. Это и есть bufferbloat, а управляется он очередями qdisc.

Проверяем текущую дисциплину очереди

tc qdisc show

Часто на современных системах вы увидите fq_codel или cake (обычно лучше для латентности), либо базовую дисциплину. На VDS многое зависит от виртуального сетевого устройства и настроек хоста, но локально всё равно полезно понять, не включили ли вы сами шейпинг.

Косвенные признаки проблем с очередями

• RTT растёт именно во время загрузки канала (бэкапы, rsync, большие ответы);

• iperf3 показывает «нормальную» скорость, но реальный веб/API «задумывается»;

• в mtr средний RTT нормальный, но Worst и разброс большие.

conntrack: проблемы NAT/файрвола и «таблица состояний переполнена»

Если VDS работает как шлюз, reverse-proxy, балансировщик, VPN или просто принимает много коротких соединений, легко упереться в conntrack. Симптомы похожи на «случайные таймауты» и нестабильность при пиках.

Быстрая проверка заполнения conntrack

sudo sysctl net.netfilter.nf_conntrack_count
sudo sysctl net.netfilter.nf_conntrack_max

Если nf_conntrack_count близок к nf_conntrack_max, высока вероятность дропов новых соединений.

Посмотреть сводку по таблице:

sudo conntrack -S

Практика: если вы упираетесь в conntrack на VPN или на проксирующем узле, обязательно фиксируйте метрики в моменты пиков, иначе «в ручном тесте» всё будет выглядеть нормально.

PMTUD и MTU: «всё пингуется, но HTTPS висит»

PMTUD (Path MTU Discovery) нужен, чтобы TCP выбрал максимальный размер пакета без фрагментации. Если на пути ломаются ICMP-сообщения «Fragmentation Needed», возникает эффект PMTUD black hole: маленькие пакеты проходят, а большие — нет. В итоге TLS/HTTP2/крупные ответы могут зависать, появятся ретрансмиты и странные таймауты.

Проверка MTU на интерфейсе

ip link show

Подозрительные случаи: вы выставили MTU 9000, но где-то на пути 1500; либо поверх VPN/туннеля MTU стало меньше, а MSS не подрезается.

Проверка PMTU до узла (без фрагментации)

Идея: отправить ICMP с флагом DF (don’t fragment) и подобрать размер. На Linux это делается через ping:

ping -M do -s 1472 198.51.100.25

Число 1472 — это 1500 минус заголовки IP/ICMP. Если не проходит, уменьшайте. Если в какой-то точке начинается «Frag needed and DF set» — PMTUD работает. Если вместо этого тишина и ретраи — возможна «чёрная дыра» по ICMP.

Если вы диагностируете проблемы в туннелях, пригодится отдельный румбук по keepalive/роумингу и «плавающим» маршрутам: WireGuard roaming и keepalive: типовые сетевые грабли.

nic offload: когда tcpdump «врёт», а ретрансмиты есть

На виртуальных NIC и при включённых offload-фичах (TSO/GSO/GRO) пакетная картина на хосте может отличаться от того, что реально «на проводе». Из-за этого в tcpdump иногда видно «крупные» сегменты или, наоборот, не видно ожидаемой сегментации.

Проверить offload на интерфейсе (например, eth0):

sudo ethtool -k eth0

Временно отключить часть offload для диагностики (делайте аккуратно: это может повлиять на производительность):

sudo ethtool -K eth0 gro off gso off tso off

После тестов лучше вернуть как было (или перезагрузить, если настройки не постоянные).

tcpdump: снимаем доказательства и ловим проблему в пакеты

tcpdump включаем, когда метрики уже намекают на причину, но нужно подтверждение: повторные передачи, отсутствие ACK, проблемы с MSS/MTU, неожиданные RST, асимметрия трафика.

Безопасные принципы съёма дампа

• Фильтруйте трафик: по хосту, порту, подсети. Иначе получите гигабайты и лишнюю нагрузку.

• Ставьте лимиты: по размеру и ротацию файлов.

• Помните о чувствительных данных: дамп может содержать токены, cookies и полезную нагрузку.

Снять дамп для конкретного сервиса и клиента

Например, трафик TCP/443 между VDS и конкретным клиентом:

sudo tcpdump -i any -nn -s 0 -w /tmp/https-client.pcap host 198.51.100.25 and tcp port 443

Если нужно посмотреть «живьём», но не сохранять:

sudo tcpdump -i any -nn host 198.51.100.25 and tcp port 443

Ротация по файлам (чтобы не съесть диск)

sudo tcpdump -i any -nn -s 0 -C 100 -W 5 -w /tmp/cap.pcap host 198.51.100.25 and tcp port 443

Это создаст до 5 файлов по 100 МБ (старые будут перезаписываться по кругу).

Флаги TCP: быстро поймать RST/SYN/FIN

Для «событийного» среза удобно смотреть хотя бы флаги:

sudo tcpdump -i any -nn 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0)'

Это не анализ ретрансмиссий, но помогает понять, не рвутся ли соединения из-за RST или постоянных пересозданий.

Проверка MSS на уровне SYN

Если подозрение на MTU/PMTUD, полезно посмотреть MSS в SYN/SYN-ACK. Фильтр на handshake:

sudo tcpdump -i any -nn -vv 'tcp port 443 and (tcp[tcpflags] & (tcp-syn) != 0)'

В выводе ищите опцию MSS. Если она завышена для туннеля, это подсказка: вероятно, нужен MSS clamping на границе туннеля или на шлюзе.

Собираем картину: как связать iperf3, mtr, ss и tcpdump

Хорошая диагностика — это не «сделал 20 команд», а связал наблюдения в причинно-следственную цепочку.

Сценарий 1: низкая скорость, но RTT стабильный и потерь нет

• mtr: потерь нет, RTT ровный.

• iperf3: один поток низко, много потоков лучше.

• ss -ti: низкий cwnd и/или признаки, что single-stream не раскрывает полосу.

Вывод: ограничение не обязательно «канал плохой». При большом RTT один поток TCP может не раскрывать полосу. Используйте параллелизм на приложении (HTTP/2 помогает), проверьте лимиты на стороне сервиса, а также ретрансмиты (даже небольшие потери сильно режут single-stream).

Сценарий 2: периодические таймауты, всплески RTT, ретрансмиты

• mtr: на цели иногда появляются потери или растёт Worst.

• ss -ti: растёт retrans, RTT и rttvar.

• tcpdump: видно «рваную» картину: повторы, паузы, нет ACK, или много RST.

Вывод: похоже на реальную деградацию канала или перегруз на пути. Дальше важно понять, где именно: сравнить тесты до разных точек (например, до соседней VDS в той же локации и до внешнего узла), а также проверить, не попадаете ли вы в шейпинг/очереди на исходящем трафике.

Сценарий 3: «пингуется, но HTTPS зависает»

• ping маленьким размером проходит, загрузка больших объектов рвётся.

• ss: много ретрансмиссий при отправке крупных сегментов.

• tcpdump: MSS выглядит завышенным, ICMP «frag needed» не наблюдается, соединение «жует» ретраи.

Вывод: проверять MTU/PMTUD, фильтрацию ICMP, туннели/VPN и MSS clamping. Это один из самых частых «мистических» кейсов.

Мини-румбук: что собрать перед обращением в поддержку/к провайдеру

Если вы дошли до момента, когда нужны действия на стороне площадки или маршрута, соберите короткий, но полный пакет фактов. Это ускорит решение.

• Время и длительность проблемы, периодичность, затронутые направления (страны/провайдеры, конкретные IP).

• Вывод mtr -rwzbc 200 до проблемного узла (ICMP и при необходимости TCP -T -P 443).

• Результаты iperf3 (single, -P 4 и -R) с указанием точки сервера.

• Срез ss -ti для проблемных соединений (или для порта сервиса).

• Один pcap-файл tcpdump с узким фильтром на 20–60 секунд (если уместно и допустимо по политике безопасности).

• Информация об интерфейсе: ip link show, MTU, и при необходимости ethtool -k (offload).

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Если проблема проявляется именно на TLS (нестабильные рукопожатия, странные обрывы, несоответствие домена/сертификата), проверьте и «прикладной слой»: SNI/ALPN, цепочки и актуальность сертификата. Для публичных сервисов удобнее держать корректные SSL-сертификаты и планово обновлять их, чтобы в расследовании сети не путать транспортные сбои с ошибками TLS.

Итоги

В сетевой диагностике на VDS важно не «перебирать инструменты», а последовательно сужать область поиска. iperf3 показывает, есть ли полоса и в каком направлении; mtr помогает локализовать деградацию по маршруту и увидеть RTT/packet loss; ss даёт правду про TCP: очереди, retransmits, оценку RTT; tcpdump превращает гипотезы в доказательства на уровне пакетов. А такие системные темы, как qdisc, conntrack, pmtud и nic offload, часто объясняют «странные» и плавающие симптомы.

Держите этот румбук под рукой и старайтесь всегда сравнивать: «как выглядит норма» и «как выглядит деградация» на одинаковых командах. Это самый быстрый путь к причине и к корректному запросу в поддержку.