Почему VPN тормозит: расстояние, накладные расходы, MTU и путь

VPN бывает медленным по одной из пяти причин, и их легко различить, если измерить. Расстояние: каждый пакет теперь идёт до VPN-сервера и обратно, и если сервер далеко, за это платит каждое соединение. Потери на пути: TCP резко замедляется, когда пакеты пропадают, а чем длиннее путь, тем больше для этого возможностей. CPU: шифрование стоит процессорного времени на клиенте и на сервере, и маленький сервер или старый роутер упираются в потолок. MTU: обёрнутые пакеты больше не помещаются, часть из них молча отбрасывается, и одни сайты зависают, а другие работают нормально. И сеть посередине: провайдер, который плохо маршрутизирует ваш трафик до сервера, замедляет трафик, который не может опознать, или просто перегружен по вечерам. Тест скорости с выключенным и включённым VPN, ping до сервера, один тест MTU и один запуск mtr покажут, в чём дело.

Остальная часть статьи - о том, как провести эти тесты, как их читать и что исправляет каждую причину, включая честный ответ, когда исправление - «сервер поближе к вам», которого никакая настройка никогда не заменит.

Измерьте, прежде чем что-то менять#

Меняйте по одной вещи за раз и начинайте с чисел. Пять измерений покрывают почти любой случай:

1. Тест скорости с выключенным VPN до тестового сервера рядом с местоположением VPN-сервера.
2. Тот же тест с включённым VPN.
3. ping до адреса VPN-сервера с выключенным VPN в течение минуты, с записью среднего значения и потерь.
4. mtr (или WinMTR, или pathping в Windows) до адреса VPN-сервера, тоже с выключенным VPN.
5. Тест MTU через ping большими пакетами, описанный ниже.

Тестируйте с выключенным VPN до сервера рядом с VPN-сервером, а не рядом с вами. Иначе вы сравниваете короткий путь с длинным и вините туннель в расстоянии.

Расстояние и почему оно стоит больше, чем задержка#

Свет в оптоволокне проходит около 200 км за миллисекунду, поэтому каждые 1000 км пути добавляют около 10 мс к времени приёма-передачи ещё до того, как пакета коснётся какое-либо оборудование. Реальные маршруты длиннее прямой линии. Таблица реалистичных значений из разных городов до Франкфурта есть в статье задержка, джиттер и потеря пакетов.

Задержка не только создаёт ощущение вялости. Она ограничивает, насколько быстро может работать одно TCP-соединение, если есть хоть какие-то потери пакетов. Полезная грубая модель (формула Мэтиса, для классического управления перегрузкой) говорит, что пропускная способность TCP-соединения не превышает примерно размер сегмента, делённый на время приёма-передачи, умноженное на квадратный корень из доли потерь.

Воспринимайте это как иллюстрацию формы зависимости, а не как прогноз: современное управление перегрузкой, например BBR, гораздо менее чувствительно к случайным потерям, а браузеры открывают сразу несколько соединений. Вывод всё равно верен. Удвоение расстояния до VPN-сервера примерно вдвое уменьшает то, что канал с потерями может пропустить через одно соединение, поэтому VPN, который утром работает нормально, оживлённым вечером может казаться сломанным.

VPN добавляет расстояние всякий раз, когда сервер не лежит на пути туда, куда вы идёте. Если вы в Берлине, а сайт во Франкфурте, VPN во Франкфурте почти ничего не стоит. Если сайт тоже в Берлине, каждый пакет теперь едет во Франкфурт и обратно.

Накладные расходы протокола и стоимость шифрования#

Каждый VPN добавляет к каждому пакету заголовки. В пропускной способности это стоит немного:

Если ваш VPN на 5% медленнее канала, это накладные расходы, и исправлять нечего. Если на 50% - дело в чём-то другом.

Шифрование стоит CPU, и стоимость растёт с пропускной способностью. Телефоны и ноутбуки последних нескольких лет без труда шифруют сотни мегабит в секунду. Слабые места - старые роутеры с VPN-клиентом, дешёвые одноплатные компьютеры и маленькие серверы. На стороне сервера стоимость считается на байт по всем подключённым устройствам, поэтому серверу, которым одновременно пользуется вся семья, нужно больше CPU, чем серверу одного телефона.

Потолок CPU виден в цифрах: пропускная способность останавливается на одном и том же значении независимо от скорости канала, а график CPU клиента или сервера во время теста упирается в предел. На арендованном сервере с жёстким ограничением CPU потолок - это и есть ограничение; более быстрый канал не поможет, поможет тариф побольше.

MTU: когда одни сайты зависают, а другие работают#

Классический симптом MTU достаточно странный, чтобы сам по себе быть диагнозом: VPN подключается, мелочи работают, а определённые сайты или большие загрузки зависают навсегда. Происходит вот что: обёрнутые пакеты теперь больше, чем допускает какой-то участок пути, слишком большие пакеты отбрасываются, а сообщение, которое должно сказать отправителю уменьшить их (ICMP «fragmentation needed»), где-то блокирует файрвол. Маленькие пакеты проходят, большие исчезают.

Стандартный MTU Ethernet - 1500 байт. У соединений PPPoE, распространённых на DSL и некоторых оптических линиях, - 1492. У мобильных сетей и некоторых туннелей меньше. Инструменты WireGuard по умолчанию ставят MTU туннеля 1420, исходя из пути в 1500 байт и накладных расходов IPv6; на линии PPPoE безопаснее 1412 или меньше.

Найдите самый большой пакет, который проходит без фрагментации. Размер полезной нагрузки плюс 28 байт (20 на заголовок IP, 8 на заголовок ICMP) - это MTU пути.

Windows:  ping -f -l 1472 1.1.1.1Linux:    ping -M do -s 1472 1.1.1.1macOS:    ping -D -s 1472 1.1.1.1

Если 1472 не проходит с ошибкой «требуется фрагментация» или «message too long», уменьшайте размер, пока не пройдёт. Если проходит 1464, MTU пути - 1492, значение для PPPoE. Затем установите MTU туннеля равным MTU пути минус накладные расходы VPN.

Соединения на основе Xray страдают от этого гораздо меньше, чем WireGuard или OpenVPN, потому что они проксируют TCP-потоки, а не заворачивают IP-пакеты: каждый конец подбирает размер сегментов средствами самого TCP под реальный путь. У клиентов в режиме VPN или TUN всё равно есть виртуальный интерфейс с настройкой MTU, и необычно высокое значение там может создавать проблемы UDP-приложениям; значения по умолчанию разумны, так что не трогайте их без измеренной причины.

Сеть посередине#

Часто с туннелем всё в порядке, а с дорогой, по которой он идёт, - нет.

Маршрутизация провайдера. Ваш провайдер решает, как ваш трафик попадёт в сеть VPN-сервера - через каких транзитных провайдеров и какие точки обмена. Плохой маршрут может добавить 30 мс и перегруженный участок по дороге. mtr показывает, где скачет задержка и где начинаются потери; как отличить настоящие потери от роутера, который просто понижает приоритет ответов на пробы, объясняет статья как читать traceroute и mtr.

Вечерняя перегрузка. Домашние сети рассчитаны на среднюю нагрузку, а вечерний пик - время, когда заполняются каналы между провайдерами. VPN, который тормозит с 20:00 до 23:00 и нормально работает в полдень, почти всегда упирается в перегруженный участок пути, а не в сервер.

Шейпинг и замедление. Некоторые сети намеренно замедляют трафик, который классифицируют как VPN, или международный трафик вообще. Хороший тест - сравнить на одном канале VPN, который выглядит как VPN, и VPN, который выглядит как обычный HTTPS: если замаскированный быстрее, что-то на пути по-разному обращается с протоколами.

Ваш собственный wifi. Прежде чем винить что-то подальше, проверьте по кабелю. Ноутбук в двух стенах от роутера на переполненном канале 2,4 ГГц может сам по себе терять несколько процентов пакетов, а как показывает таблица выше, потери - это то, что TCP ненавидит больше всего.

TCP внутри TCP и UDP внутри TCP#

То, как VPN несёт трафик, меняет его реакцию на потери.

• WireGuard и OpenVPN поверх UDP заворачивают ваши пакеты в UDP. Если один потерян, TCP-соединение внутри это замечает и восстанавливается. Один уровень повторной передачи, который ведёт себя нормально.
• OpenVPN поверх TCP заворачивает ваши TCP-соединения в ещё одно TCP-соединение. Когда пакет теряется, оба уровня повторяют передачу по своим таймерам, и при постоянных потерях пропускная способность внутреннего соединения может обвалиться. Используйте OpenVPN поверх TCP, только когда UDP заблокирован.
• Xray проксирует потоки: ваше TCP-соединение заканчивается на клиенте, а на сервере начинается новое, и байты между ними идут по TLS-соединению. Для веб-трафика это избавляет от проблемы двойной повторной передачи. UDP-трафик, например игры и звонки, ретранслируется по тому же TCP-соединению, поэтому потерянный пакет задерживает всё, что идёт за ним, пока его не перешлют. На чистом пути это незаметно; на пути с потерями приложения реального времени подтормаживают.

Последний пункт - причина, по которой VPN, устойчивый к цензуре, не является игровым ускорителем. Когда туннель помогает игре, а когда лишь добавляет расстояние, разобрано в статье снижает ли VPN пинг в играх.

Проблемы на устройстве#

Режим прокси вместо режима VPN. Браузер идёт через прокси, а менеджер загрузок или лаунчер игры - нет, и вы тестируете не то. Проверьте, в каком режиме работает клиент.

Оптимизация батареи. Android может ограничивать VPN-приложение, работающее в фоне. Исключите VPN-клиент из оптимизации батареи, если соединение постоянно обрывается при выключенном экране.

Защитное ПО, инспектирующее HTTPS. Антивирусные пакеты, перехватывающие TLS, добавляют собственную обработку к каждому соединению, с VPN или без, а некоторые плохо уживаются с VPN-адаптерами.

Два VPN. Рабочий и личный VPN или VPN и файрвол, работающий как локальный VPN, дают пересекающиеся маршруты и непредсказуемые пути.

DNS на дальнем конце. С полным туннелем каждое новое имя хоста стоит одного обращения к серверу и обратно ещё до того, как начнётся соединение с сайтом. На пути в 100 мс страница, которая обращается к тридцати доменам, кажется медленнее, чем позволяет её пропускная способность. Это цена отсутствия утечек DNS, и собственные кэши браузеров смягчают её после первого посещения.

Приватный сервер: что можно исправить, а что нельзя#

На собственном сервере две из пяти причин частично под вашим контролем. CPU: в линейке приватных VPN RE:NODE тарифы рассчитаны по тому, сколько устройств пользуется сервером одновременно, доля CPU - жёсткое ограничение, а графики в панели показывают CPU относительно этого ограничения, так что потолок можно увидеть, а не угадывать. И конкуренция: на вашем сервере больше никого нет, поэтому за него соревнуются только ваши устройства. О выборе размера - статья сколько устройств можно подключить к VPN.

Расстояние вам неподвластно. Сервер работает на Xray с VLESS и Reality в одном месте - в Германии. Из большей части Европы это короткий путь; из более далёких мест каждое соединение платит за расстояние так, как описано выше, и никакой тариф не изменит физику. Ограничения трафика нет, поэтому медленный туннель никогда не означает тихо применённую квоту. В некоторых странах использование VPN ограничено; узнайте местный закон, прежде чем на него полагаться.

FAQ#

Какая потеря скорости с VPN нормальна?

С близким сервером и достаточно мощным устройством нормально 5-15% ниже скорости канала - в основном накладные расходы и чуть более длинный путь. Потеря половины и больше указывает на расстояние, потери, потолок CPU или проблемы с MTU, и измерения выше покажут, на что именно.

Почему VPN быстрый в мобильной сети и медленный в wifi?

VPN тот же, значит, разница в локальной сети: сигнал и помехи wifi, домашний роутер или другой маршрут провайдера до сервера. Сначала проверьте по кабелю, чтобы исключить wifi, затем сравните mtr из обеих сетей.

Станет ли VPN быстрее с более быстрым тарифом на интернет?

Только если узким местом был канал. Если предел - расстояние вместе с потерями, CPU на одном из концов или перегруженный участок между провайдерами, более быстрый тариф ничего не изменит. Сначала сравните скорость без VPN до сервера рядом с VPN-сервером.

Стоит ли уменьшить MTU, чтобы ускорить VPN?

Только если тест большими пакетами показывает, что путь не пропускает пакеты полного размера, или вы видите классический симптом с зависанием некоторых сайтов. Уменьшение MTU, когда всё в порядке, немного снижает пропускную способность, потому что каждый пакет несёт меньше данных при тех же заголовках.

Почему вечером VPN медленнее?

Скорее всего, из-за перегрузки между вашим провайдером и сетями, которые несут трафик до сервера, - вечерний пик заполняет эти каналы. Запустите mtr в спокойное время и в медленное и сравните, где появляются потери.