ВПН режет скорость

Просадка в туннеле складывается из шести слоёв: задержки маршрута, служебной обёртки пакета, фрагментации, цены шифра, транспорта (TCP или UDP) и ширины порта площадки. Пока не сняты скорость без туннеля и реальный MTU, перебор протоколов бессмыслен.

Коротко. Тысяча километров чистого волокна стоит 9,8 мс отклика, реальный маршрут — втрое больше. WireGuard добавляет 32 байта, с UDP и IP выходит 60 (IPv4) или 80 (IPv6) — по худшему случаю wg-quick и вычитает 80: 1500 даёт 1420, PPPoE 1492 — 1412. На полном пакете это ≈4% полосы (IPv4) и ≈5,3% (IPv6), на мелких — до 2,7 раза. Порядок диагностики: порт площадки → MTU → транспорт → шифр.

Почему ВПН режет скорость на дальнем сервере?

Тысяча километров волокна — это 9,8 мс «туда-обратно». Свет в вакууме идёт 299 792 458 м/с (CODATA), групповой показатель преломления OS2 (ITU-T G.652) — 1,466–1,467: отсюда 204 358 км/с и 4,89 мкс на километр в одну сторону.

Реальная трасса длиннее: у Singla и соавторов (arXiv:1505.03449) медианный минимальный ping в 3,2 раза выше вакуумного предела — 1000 км по карте дают 6,67 × 3,2 ≈ 21 мс. Задержка превращается в мегабиты через окно TCP: по RFC 7323 поле окна 16-битное, без масштабирования сессия ограничена 64 КиБ на круг — при RTT 100 мс это ~5,2 Мбит/с на поток. Выбор локации — в материале какая страна лучше для ВПН.

Сколько байтов забирает служебная обёртка?

Тридцать два байта на пакет плюс транспортные заголовки: сообщение WireGuard несёт 16 байт заголовка и 16 байт тега ChaCha20-Poly1305 (MESSAGE_MINIMUM_LENGTH = 32 в драйвере).

Худший случай — IPv6: 32 байта WireGuard, 8 UDP и 40 IPv6 дают 80. Эти 80 и вычитает из MTU маршрута скрипт wg-quick, поэтому при 1500 в канале туннель получает 1420. На PPPoE канал отдаёт 1492 (RFC 2516: 6 байт PPPoE и 2 байта Protocol ID), туннелю остаётся 1412, а оставленное 1420 обрубит крупные пакеты.

Второй расход — паддинг до кратности 16: пустой TCP-ACK в 40 байт уезжает в канал как 108.

Чем опасна фрагментация?

Тем, что не менее 28% путей в выборке вообще не пропускали пакеты с IPv6-заголовком Fragment — данные RFC 7872, которые приводит RFC 8900. Там же: сборка держит состояние неопределённое время, а на высоких скоростях 16-битного поля Identification не хватает и дейтаграммы собираются неверно.

Хуже фрагментации — её отсутствие вместе с потерей ICMP: сообщение «нужна фрагментация» не доходит, Path MTU Discovery отказывает, возникает чёрная дыра — короткие обмены проходят, первая крупная передача виснет. Отсюда очерёдность: сначала MTU, потом протоколы, как в материале почему ВПН не работает на роутере.

Что быстрее — ChaCha20 или AES-GCM?

Зависит от процессора. Замеры из приложения к RFC 8439: OMAP 4460 — 24,1 МБ/с у AES-128-GCM против 75,3 у ChaCha20-Poly1305, Xeon Sandy Bridge с AES-NI — наоборот, 900 против 500.

Но шифр редко бывает узким местом: в замерах авторов WireGuard он дал 1011 Мбит/с при отклике 0,403 мс, IPsec с AES-GCM — 881 Мбит/с, а OpenVPN по UDP — 258 Мбит/с при 1,541 мс. Отставание даёт работа OpenVPN в пространстве пользователя, а не шифр.

Почему туннель поверх TCP медленнее UDP?

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

Жёсткой привязки протокола к транспорту нет. XRay Reality работает поверх TCP; Shadowsocks (shadowsocks.org/doc) и Cloak (github.com/cbeuw/Cloak) умеют оба транспорта, и UDP-режим включают явно; WireGuard, AmneziaWG и IKEv2 — только UDP. Кадровка стоит байтов: Shadowsocks AEAD тратит на чанк 34 байта, а у Xray в mKCP потолком становятся умолчания — mtu 1350 и downlinkCapacity 20 МБ/с.

Сколько отдаёт порт вашей площадки?

Ровно столько, сколько записано в тарифе: у Hetzner это 1 Гбит/с с безлимитным трафиком (на 10-гигабитном аплинке включено 20 ТБ в месяц), а у бесплатной формы Oracle VM.Standard.E2.1.Micro — 50 Мбит/с наружу при 10 ТБ исходящих. Указанные там же 480 Мбит/с — это трафик внутри региона и к приватным адресам, а не в интернет (данные на 15.08.2026). При домашних 500 Мбит/с микроформа упрёт вас в десятую часть канала — площадки сопоставлены в сравнении VPS-хостингов.

Как правильно измерить просадку?

Базовая линия — три собственных прогона без туннеля в тот же час, по медиане, а не цифра из договора.

1. Снимите базу. Без туннеля, три прогона, медиана; запомните сервер измерения.
2. Зафиксируйте сервер. С туннелем спидтест выберет другой узел — верните прежний.
3. Повторите с туннелем. Та же сеть и час, три прогона, сравнение медиан.
4. Проверьте канал до сервера. iperf3 -s на сервере и iperf3 -c <адрес> -t 30 -P 4 на клиенте, затем то же с -R: умолчания в один поток и 10 секунд занижают результат.

Провал только в отдельные часы — другая причина: ВПН не работает днём и вечером.

Как проверить MTU командой ping?

Пакетом с запретом фрагментации, но флаги разные: в Linux -f — не запрет фрагментации, а flood-ping.

• Windows: ping -f -l 1472 <адрес> — -f ставит Do not Fragment, -l задаёт размер данных ICMP. Крупный пакет даёт «Packet needs to be fragmented but DF set.»; снижайте размер шагами по 10, потом по 1.
• Linux: ping -M do -s 1472 <адрес> — -M do выставляет DF, -s задаёт размер. Ошибки: «Frag needed and DF set (mtu = …)» от маршрутизатора и «local error: message too long, mtu=…» от стека.

К найденному максимуму прибавьте 28 байт (8 ICMP и 20 IP) — это MTU канала, вычтите 80 — MTU туннеля. Значение 1280 проходит везде, но отдаёт на 10% меньше данных на пакет: это диагностика, а не настройка.

Симптом, причина, решение

Разбор идёт сверху вниз: порт, MTU, транспорт, в конце шифр. Расчётные 4% (IPv4) и 5,3% (IPv6) — норма, всё сверх объясняют маршрут, фрагментация или чужой переполненный сервер.

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

Ниже — короткие ответы на частые вопросы о просадке скорости.

Материал научно-технический. Прямой ответственности за использование VPN физическим лицом законодательство РФ не устанавливает.