Ниже — практическая пошаговая методика и набор команд, которые помогут локализовать проблему (провайдер → VPN‑сервер → «далёкие» хосты) и понять, где именно теряется скорость/появляются задержки.
Общие принципы
- Сравнивайте одни и те же тесты «через VPN» и «без VPN». Это самый быстрый способ понять, где проблема.
- Делайте несколько проб в разное время (утро/вечер), сохраняйте выводы — поведение нестабильно.
- Большая задержка/потеря пакетов обычно указывает на проблемы маршрута/провайдера; низкая пропуская способность при нормальном пинге — на ограничение пропускной способности, CPU/шифрование на сервере или переполнение очередей (bufferbloat).
- ICMP/трассировка иногда обрабатываются по‑другому (роутеры могут отбрасывать ICMP), поэтому используйте и TCP‑traceroute и реальные TCP/HTTP тесты.
1) Быстрая проверка состояния сервера (на самом VPN‑сервере)
- Нагрузка и использование CPU/RAM:
top -bn1 | head -n15
uptime
free -m
vmstat 1 5
Что смотреть: CPU 1‑ядро на 100% при передаче трафика — возможно шифрование/ограничение. ОЗУ и swap — не должны вызывать сильного свопинга.
- Сетевые интерфейсы и ошибки:
ip -s link show dev eth0
cat /proc/net/dev
ethtool -S eth0 (если поддерживается)
Что смотреть: ошибки rx/tx, drops, overruns, collisions.
- Прерывания и распределение по CPU:
cat /proc/interrupts
Что смотреть: если один CPU обрабатывает почти все прерывания NIC — возможен узкий «single CPU» лимит.
- Очереди и qdisc:
tc qdisc show dev eth0
Что смотреть: fq_codel/tbf/pfifo — bufferbloat/queueing может вызывать сильные задержки при загрузке.
2) Простые сетевые тесты (на клиенте и на сервере)
- Ping:
ping -c 20 <VPN_server_ip> # пинг до VPN‑сервера
ping -c 20 <gateway_of_server> # шлюз датацентра/провайдера (ip route)
ping -c 20 8.8.8.8 # общедоступный DNS
ping -c 20 <target_site_ip> # проблемный сайт по IP
Что смотреть: RTT (ms) и packet loss. В пределах города RTT обычно <20–30ms. Для одного и того же города 800 ms — очень плохо и указывает на маршрутизационный/провайдерский баг.
- Тест MTU (фрагментация):
ping -M do -s 1472 <VPN_server_ip>
ping -M do -s 1472 <target_ip>
(уменьшайте size пока не пойдёт)
Что смотреть: если большие пакеты теряются — возможно MTU/MSS неверны (особенно важно для VPN).
- traceroute (ICMP/UDP/TCP):
traceroute -n <target_ip>
traceroute -T -p 443 -n <target_ip> # TCP по 443
tracepath <target_ip>
Что смотреть: резкий рост задержки/потери на каком‑то хопе — смотрите именно на первый «плохой» хоп. Если первый хоп (сервер/его шлюз) плох — проблема у хостера. Если первый хоп норм, дальше — у провайдера/межсети.
- MTR — комбинированная трассировка с длительной статистикой:
mtr --report --report-cycles 100 <target_ip>
или mtr -rwzc 100 <target_ip>
Что смотреть: Loss% и Avg/Best/Worst. Потеря пакетов на одном хопе и далее — серьёзный признак проблемы в том сегменте. Но помните: некоторые роутеры «пускают» ICMP в очередь, а TCP‑пакеты проходят — параллельно делайте TCP‑тесты (см. ниже).
3) Пропускная способность: iperf3
- На сервере (VPN‑сервере) запустите:
iperf3 -s
- На клиенте:
iperf3 -c <vpn_server_ip> -P 4 -t 60 # многопоточность (параллельные потоки)
iperf3 -c <vpn_server_ip> -R -P 4 -t 60 # реверс (сервер->клиент)
- Тесты UDP:
iperf3 -c <vpn_server_ip> -u -b 100M -t 30
- Что смотреть: пропускная способность в обе стороны, packet loss (UDP), jitter. Если iperf3 показывает высокую скорость, а браузеры/одиночные TCP запросы медленные — это ограничение на число соединений/производительность одного TCP‑соединения или проблема с RTT/потерями/retransmits.
- Если не можете запускать iperf3 на клиенте, можно использовать публичные iperf серверы (RIPE/iperf‑server list), но лучше тест на двух контролируемых машинах.
4) Транспортные показатели TCP (retransmits, cwnd)
- ss и статистика:
ss -s
ss -ti dst <client_ip>
netstat -s | grep retrans
- tcpdump для наблюдения за ретрансмиссиями:
tcpdump -i eth0 host <client_ip> and tcp -w capture.pcap
(анализ в Wireshark: ищите [TCP Retransmission], [Dup ACK], высокое RTT)
- Что смотреть: много retransmits/dup ACK — потери на пути -> пропускная способность TCP упадёт.
5) HTTP/реальные загрузки
- curl — измерить время соединения и скорость:
curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} %{size_download} %{speed_download}\n' http://<target>/<bigfile>
- wget — скачивание большого файла и смотреть скорость.
- Если изображения грузятся «по пикселям» — похоже на низкие скорости на отдельных TCP‑потоках или частые ретрабы.
6) Speedtest (как дополнение)
- Установите speedtest-cli или Ookla speedtest:
speedtest --list | grep "<город>" # найти сервер в том же городе
speedtest --server-id <id>
- Также проверяйте ping/скорость до сервера в том же датацентре, где VPN.
- Что смотреть: ping и Mbps. Высокий ping и малая скорость даже до ближайшего speedtest сервера — проблема на пути к VPN/на сервере.
7) Диагностика VPN конкретно
- WireGuard:
wg show
Что смотреть: handshake last handshake recent/age. Если «last handshake» старый — возможные drop.
- OpenVPN:
systemctl status openvpn
смотрите логи /var/log/openvpn.log, статистику connections.
- Проверьте CPU при активных связях: шифрование может быть CPU‑интенсивным. На дешёвых VPS один поток OpenSSL на 1 ядро может загружаться на 100% и лимитировать скорость.
- Проверьте offload/TSO/GSO/GRO:
ethtool -k eth0
Если есть баги в виртуализации, иногда нужно выключить offload (ethtool -K eth0 gro off gso off tso off) — иногда это помогает при проблемах с VPN.
8) Дополнительно: queueing / bufferbloat
- Тест на bufferbloat (время отклика при загрузке):
sudo apt install busybox-syslogd # либо используйте встроенные утилиты
Используйте «flent» или «speedtest + ping» одновременно. Но проще: смотрите tc qdisc и используйте iperf3 с мониторингом ping.
- Если при заливке канала пинг растёт в разы — есть bufferbloat; решение — настраивать fq_codel/htb.
9) DNS и SNI‑фильтрация (особенно для «заблокированных через провайдера сайтов»)
- Проверка DNS разрешения:
dig +short @1.1.1.1 example.com
dig +trace example.com
- Иногда «блокировка» по SNI/HTTP может вызывать задержку (провайдер вставляет страницы с задержкой). Проверьте, меняется ли поведение при подключении к сайтам по IP прямо (если сайт поддерживает virtualhosts, это может не работать).
10) Что именно тестировать — список адресов/хопов
- 1) VPN‑сервер публичный IP (и его gateway): ping/traceroute/iperf.
- 2) Провайдерский/датацентровый шлюз (по умолчанию route): ip route show; ping gateway.
- 3) Публичные стабильные хосты: 8.8.8.8, 1.1.1.1, speedtest сервер в том же городе (из списка speedtest).
- 4) Непосредственно проблемные сайты (по IP и по имени).
- 5) Некоторые backbone‑узлы: через traceroute вы увидите AS‑хопы; если проблема на конкретном AS — это видно в mtr.
11) Интерпретация результатов (коротко)
- Высокий RTT/потери уже на первом хопе (шлюз сервера) → проблема у хостера/VPN‑сервера/датацентра.
- Нормальный RTT до VPN‑сервера, но высокие задержки/потери уже после него → проблема у провайдера, межсетевого соединения или целевого сайта/AS.
- Низкая скорость iperf3 в обе стороны + высокий CPU на сервере → CPU/шифрование/виртуализация узкая точка.
- iperf3 показывает нормальную скорость, но браузеры/одиночные HTTP медленные → проблема с losses/jitter/высоким RTT (влияет на single TCP поток), буферизацией или QoS.
- MTR показывает потерю пакетов на одном хопе и далее — это признак реальной потери. Но если потеря видна только на промежуточных хопах и не на конечном — возможно роутер контролирует ICMP, так проверьте TCP‑уровень (iperf/tcpdump).
12) Что прислать техподдержке/хостеру (если нужно)
- Вывод mtr (можно --report --report-cycles 100) к проблемному хосту и к популярным адресам.
- iperf3 логи (client и server).
- tcpdump (короткая запись) с отметкой времени с обоих концов (если возможно).
- top/htop во время теста и вывод ip -s link, tc qdisc.
- Примеры ping (через VPN / без VPN) с датой/временем.
13) Рекомендации по модернизации/быстрым проверкам
- Попробуйте временно сменить порт/протокол VPN (TCP 443 vs UDP) — иногда провайдеры/межсетевые устройства иначе обрабатывают трафик.
- Попробуйте переключить на другой хост в том же датацентре (если есть) или сменить на другой провайдер/сервер на короткое время, чтобы увидеть, пропадает ли проблема.
- На сервере отключите TCP offload (GRO/GSO/TSO) временно, если видите странные сетевые артефакты.
Короткий чек‑лист команд, которые рекомендую выполнить и сохранить выводы:
- Состояние сервера:
top -bn1 > top.out
ip -s link show dev eth0 > link.out
cat /proc/interrupts > interrupts.out
tc qdisc show dev eth0 > qdisc.out
- Ping / MTU / traceroute / mtr:
ping -c 20 <vpn_ip> > ping_vpn.out
ping -c 20 <gateway> > ping_gw.out
ping -M do -s 1472 <vpn_ip> > ping_mtu.out
traceroute -T -p 443 -n <target> > tr_tgt.out
mtr --report --report-cycles 200 <target> > mtr_tgt.out
- iperf3:
iperf3 -s > iperf_server.log (на сервере)
iperf3 -c <vpn_ip> -P 4 -t 60 > iperf_client.log (на клиенте)
- tcpdump (коротко, 30–60 с):
tcpdump -i eth0 host <client_ip> and tcp -w capture.pcap
Если пришлёте несколько таких результатов (mtr к проблемному сайту, iperf3 лог, вывод top и ip -s link), я помогу проанализировать и скажу, на чьей стороне (провайдер/хостер/сервер/целевой сайт) скорее всего проблема и какие следующие шаги делать.