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

> ВПН режет скорость: шесть слоёв потерь — задержка маршрута, 60–80 служебных байт на пакет, MTU 1420 и 1412 на PPPoE, шифр, TCP против UDP и ширина порта.

Источник: https://vpn-ne-rabotaet.ru/ne-rabotaet/skorost/
Страница обновлена: 2026-08-17

---

**Просадка в туннеле складывается из шести слоёв: задержки маршрута, служебной обёртки пакета, фрагментации, цены шифра, транспорта (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 Мбит/с на поток. Выбор локации — в материале [какая страна лучше для ВПН](/luchshij-vpn/strana-i-region/).

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

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

| Слагаемое | IPv4 | IPv6 |
|---|---|---|
| Заголовок и тег WireGuard | 32 | 32 |
| Заголовки UDP и IP | 28 | 48 |
| Служебных на пакет | 60 | 80 |
| MTU туннеля при 1500 в канале | 1440 | 1420 |

Худший случай — 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, потом протоколы, как в материале [почему ВПН не работает на роутере](/ne-rabotaet/na-routere/).

## Что быстрее — 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-хостингов](/server/vps-sravnenie/).

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

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

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

Провал только в отдельные часы — другая причина: [ВПН не работает днём и вечером](/ne-rabotaet/vecherom-i-dnem/).

## Как проверить 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% меньше данных на пакет: это диагностика, а не настройка.

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

| Что видите | Причина | Что сделать |
|---|---|---|
| Пинг вырос вдвое, полоса та же | Длинный маршрут | Сверить с 21 мс на 1000 км |
| Один поток медленный, четыре — быстро | Окно TCP делится на RTT | Замер с `-P 4` |
| Мелкое летит, крупное виснет | MTU велик, ICMP не доходит | MTU-тест, понизить MTU |
| Потеря 4–5,3% полосы | Штатная обёртка протокола | Ничего: это цена шифра |
| Просадка на телефоне и роутере | Нет аппаратного AES | Протокол с ChaCha20 |
| Рывки при потерях | Туннель поверх TCP | Включить UDP-транспорт |
| Упор в круглое число | Ширина порта или квота | Тариф площадки |

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

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

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

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